From nobody Thu Jan 2 10:45:43 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1D120122 for ; Thu, 2 Jan 2020 10:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 3NJYe-YscZJE for ; Thu, 2 Jan 2020 10:45:35 -0800 (PST) Received: from mr85p00im-ztdg06011901.me.com (mr85p00im-ztdg06011901.me.com [17.58.23.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8AC12012A for ; Thu, 2 Jan 2020 10:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1577990722; bh=IUtz6fs7qFSkrtFqe1QLKl0/ShW/PWzuTj/H3kKKBKY=; h=From:Message-Id:Content-Type:Subject:Date:To; b=EngI/GGDjq0DmWFtgw8VKfTQB6yosrHRzNHLMcUGLlJxgg2VFCnJPUCdQTBeagi9j 9iET5EbM4qb+Hex4UnFtfxGcXg5VyW9mPVsnxvs0PV7pDdACCadadsBNLaV8gVgQbr nXi5zZselj5Yk+elb9aZ/K9b/hCDDERkZPi1Z6E1EYPguTygDPGvSV6KHa5ztZNy8A u5NpwmNaIoEFmh35cUvHpWaqabj7bKVBs8MqNAyEIELV4OSbroP8bgx8mXGTf/bdbb 9TKeKXEJbx3kYdH6UWxrdPCjPtW8+iq/RvAn5Eh8vcEaFFu+jT/0S2BcH7g6nydeCz WC0BozY9TNDQQ== Received: from [17.230.160.114] (unknown [17.230.160.114]) by mr85p00im-ztdg06011901.me.com (Postfix) with ESMTPSA id A00E1A60A57; Thu, 2 Jan 2020 18:45:22 +0000 (UTC) From: Carrick Bartle Message-Id: <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CBFF9AB2-7EFA-409C-9520-796191E7E393" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\)) Date: Thu, 2 Jan 2020 10:45:21 -0800 In-Reply-To: Cc: "Dr. Pala" , "Salz, Rich" , IETF SecDispatch , Stephen Farrell To: Eric Rescorla References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> X-Mailer: Apple Mail (2.3608.80.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-02_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2001020154 Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 18:45:39 -0000 --Apple-Mail=_CBFF9AB2-7EFA-409C-9520-796191E7E393 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > it's not useful to be prepared in that fashion > unless the algorithm that you are deploying is the one that is > eventually selected, because otherwise you just have to start over > once the selection is made. Just to be specific, do you mean, for instance, all the certificates = with the PQ algorithm that wasn't chosen would have to be revoked? > the primary rationale for doing composite key exchange now is to > defend against retrospective attacks in case a quantum computer exists > in the future. In this setting, it isn't critically important to have > the PQ algorithm be the one we eventually land on, because each > connection is separately negotiated and as long as the PQ algorithm > has some security, you're getting benegit,. In that case, would it make sense to take the next step with drafting an = intended standard for composite key exchanges (that is PQ = algorithm-agnostic)? If not, why not? Carrick > On Dec 25, 2019, at 5:57 PM, Eric Rescorla wrote: >=20 > On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle > wrote: > > How can it be true that it's too early to start developing a = protocol > > for composite keys and signatures for Web PKI when Cloudflare and > > Google have already finished a round of experiments with composite = key > > exchanges? Maybe I'm reading too much into it, but the existence of > > those experiments suggested to me that the need for = composite/composite > > implementations was imminent. (I understand that the draft in = question > > concerns signatures, not key exchanges, but apparently there isn't > > even a draft for the latter yet.) >=20 > ISTM that these cases are pretty different, in a number of respects. >=20 > First, the primary rationale for doing composite key exchange now is = to > defend against retrospective attacks in case a quantum computer exists > in the future. In this setting, it isn't critically important to have > the PQ algorithm be the one we eventually land on, because each > connection is separately negotiated and as long as the PQ algorithm > has some security, you're getting benegit,. >=20 > The primary rationale for doing PQ authentication now (or for that > matter composite authentication) is to be prepared for the day when QC > exists and we are therefore unable to rely on classical > algorithms. However, it's not useful to be prepared in that fashion > unless the algorithm that you are deploying is the one that is > eventually selected, because otherwise you just have to start over > once the selection is made. >=20 > Moreover, in order to be truly prepared, what you need isn't > principally relying party deployment, but rather authenticating party > (in the case of the WebPKI, server-side) deployment. The reason for > this is that in the world where a QC exists, you don't have protection > until the relying party refuses to accept the classical credential > [0], and at present, any client which does so will effectively be > unable to communicate. And in order to make that happen, relying > parties will have to require a post-quantum algorithm (most likely as > a composite) and that's something I don't expect them to be willing to = do > until there's widespread agreement on what that algorithm should be. >=20 >=20 > > If not now, when? After NIST crowns a winner? I don't see why it's > > necessary to wait that long given that the proposed solutions are > > algorithm-independent. And since the standardization process takes a > > while, won't waiting until then mean that there won't be a standard > > until after it's needed? >=20 > No, i don't think so. >=20 > For the reasons above, ISTM that real deployment will have to wait > until we have a selected algorithm. One could, as you suggest, deploy > some sort of multi-algorithm container, but IMO we will be far better > off just deploying new composite algorithms as if the were single > new algorithms, in the same way as we have done for key establishment. >=20 > For this reason, I think we ought to wait until there is a consensus > PQ signature algorithm, at least for the WebPKI. >=20 > -Ekr >=20 > [0] This is why this kind of composite isn't helpful in the world > where a secret QC exists not. >=20 >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --Apple-Mail=_CBFF9AB2-7EFA-409C-9520-796191E7E393 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
it's = not useful to be prepared in that fashion
unless the = algorithm that you are deploying is the one that is
eventually selected, because otherwise you just have to start = over
once the selection is = made.

Just to be specific, do you mean, for instance, all the = certificates with the PQ algorithm that wasn't chosen would have to be = revoked?

the primary rationale for doing = composite key exchange now is to
defend against = retrospective attacks in case a quantum computer exists
in = the future. In this setting, it isn't critically important to have
the PQ algorithm be the one we eventually land on, because = each
connection is separately negotiated and as long as = the PQ algorithm
has some security, you're getting = benegit,.

In that case, would it make sense to = take the next step with drafting an intended standard for composite key = exchanges (that is PQ algorithm-agnostic)? If not, why not?

Carrick




On Dec 25, 2019, at 5:57 PM, Eric Rescorla = <ekr@rtfm.com> = wrote:

On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle <cbartle891@icloud.com> wrote:
> How can it be true that it's too early to start = developing a protocol
> for composite keys and = signatures for Web PKI when Cloudflare and
> Google = have already finished a round of experiments with composite key
> exchanges? Maybe I'm reading too much into it, but the = existence of
> those experiments suggested to me that = the need for composite/composite
> implementations was = imminent. (I understand that the draft in question
> = concerns signatures, not key exchanges, but apparently there isn't
> even a draft for the latter yet.)

ISTM that these cases are pretty different, in a number of = respects.

First, the primary rationale for = doing composite key exchange now is to
defend against = retrospective attacks in case a quantum computer exists
in = the future. In this setting, it isn't critically important to have
the PQ algorithm be the one we eventually land on, because = each
connection is separately negotiated and as long as = the PQ algorithm
has some security, you're getting = benegit,.

The primary rationale for doing = PQ authentication now (or for that
matter composite = authentication) is to be prepared for the day when QC
exists= and we are therefore unable to rely on classical
algorithms. However, it's not useful to be prepared in that = fashion
unless the algorithm that you are deploying is the = one that is
eventually selected, because otherwise you = just have to start over
once the selection is made.

Moreover, in order to be truly prepared, what = you need isn't
principally relying party deployment, but = rather authenticating party
(in the case of the WebPKI, = server-side) deployment. The reason for
this is that in = the world where a QC exists, you don't have protection
until= the relying party refuses to accept the classical credential
[0], and at present, any client which does so will = effectively be
unable to communicate. And in order to make = that happen, relying
parties will have to require a = post-quantum algorithm (most likely as
a composite) and = that's something I don't expect them to be willing to do
until there's widespread agreement on what that algorithm = should be.


> If not now, = when? After NIST crowns a winner? I don't see why it's
> = necessary to wait that long given that the proposed solutions are
> algorithm-independent. And since the standardization = process takes a
> while, won't waiting until then mean = that there won't be a standard
> until after it's = needed?

No, i don't think so.

For the reasons above, ISTM that real = deployment will have to wait
until we have a selected = algorithm. One could, as you suggest, deploy
some sort of = multi-algorithm container, but IMO we will be far better
off= just deploying new composite algorithms as if the were single
new algorithms, in the same way as we have done for key = establishment.

For this reason, I think we = ought to wait until there is a consensus
PQ signature = algorithm, at least for the WebPKI.

-Ekr

[0] This is why this kind of composite isn't = helpful in the world
where a secret QC exists not.


_______________________________________________
Secdispatch = mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

= --Apple-Mail=_CBFF9AB2-7EFA-409C-9520-796191E7E393-- From nobody Thu Jan 2 10:51:41 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202D9120142 for ; Thu, 2 Jan 2020 10:51:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9d7bv_NUbCP for ; Thu, 2 Jan 2020 10:51:37 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D38120123 for ; Thu, 2 Jan 2020 10:51:36 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id o13so30222649ljg.4 for ; Thu, 02 Jan 2020 10:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dKr7zOkf0MzvIF592FObJFeiKQPbBIKX/tZzOvHQSgY=; b=uxpAa4NM/6BmUH+uFrRpnw/w3iZDcMyO0yfaGv0UoITVhxUoS5vNfCAAT4GO8UjzuM TjWG8GISZYprLXzCIUwVEENxiqao1HltLRJ9HYZlCGG8dPgdpNmx+g8iPwLUuHtB9i95 g9DXAXmSt+2JvOZ7b/r5/Qok8wQYbxUYsMtOdHg2jnwr6pL4RaoPjma+mhuKhQwOXSH+ wapEic/acIuY0eJjIY/MT2GD2uFBQe8U+MKNNgWYKOaXnEI0B7g0Sd3pnAIhovhi/596 QilrGWRLPqIEq37u2yaJnio7nHnN3lYaZ2lg4L4c9AjvjOXpDt3Ip+IuiQAb/KpOnT2l 3NHA== 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=dKr7zOkf0MzvIF592FObJFeiKQPbBIKX/tZzOvHQSgY=; b=NaaaBIH/qDgaVdklj+OIM96jntFH8PL2/GUBCoaAVUq+Y7q/vqx84yQnSRsigSg5Qp eC7N1mMIr0aVhlFHL7f0npn1gghLdKgzDgIUj+28jTLJ4ksHxkt1OI1fEk1IY2YSyFuU VwcVM0buxC6g/qMQ0iZifCoCOSS+Yj5o1xtMjCbeeD5CiUlq07d4LoHNwH+xnzl809uN qRdKnKgevChPHc5r9AtsW3bQIEDDtd5kYuhF4D0Dw3MpJiPlLnVn00ANaFoL9fLO/Lpi Z9n2GPIqsBOSIJq2+JGhq1TG/u+iPW9/oBxKd3JphIsVvOACOWmUmAxB4iToA2P7Y6zJ GZww== X-Gm-Message-State: APjAAAWJu478mfUZbjaFgsa4XQU44An8gAXizdbbPDABvry3Hmh57UIk knkNFcVniqJBSXxWEpvDN948qRQzqLzDscQMZAZBwA== X-Google-Smtp-Source: APXvYqx/KQhqHXgoLFHcY6Kh6+WE+X14+YBT8r7J3Pi1/bkyj99M1x2gWfk+7DhWktnhyV1iRdH3iZXGkA3NkZrUNQE= X-Received: by 2002:a2e:870b:: with SMTP id m11mr48035782lji.93.1577991094614; Thu, 02 Jan 2020 10:51:34 -0800 (PST) MIME-Version: 1.0 References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> In-Reply-To: <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> From: Eric Rescorla Date: Thu, 2 Jan 2020 10:50:58 -0800 Message-ID: To: Carrick Bartle Cc: "Dr. Pala" , "Salz, Rich" , IETF SecDispatch , Stephen Farrell Content-Type: multipart/alternative; boundary="000000000000a76234059b2cae8a" Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 18:51:39 -0000 --000000000000a76234059b2cae8a Content-Type: text/plain; charset="UTF-8" On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle wrote: > it's not useful to be prepared in that fashion > unless the algorithm that you are deploying is the one that is > eventually selected, because otherwise you just have to start over > once the selection is made. > > > Just to be specific, do you mean, for instance, all the certificates with > the PQ algorithm that wasn't chosen would have to be revoked? > Probably not. At a high level, there are two possible designs: 1. A certificate which has a composite signature in place of the classical signature and thus cannot be validated by old clients. 2. A certificate which has a PQ signature somehow attached in a way that it leaves the classical signature valid (as in an extension). In the former case, every server would need two certificates (one composite and one classical) and use signature_algorithms to distinguish which one to use. Once clients stopped liking the old PQ algorithm, then those composite certificates would become irrelevant and just be unused. In the latter case, the certificates would continue to be valid and the client could just ignore the PQ part of the signature. What "start over" means in this case is get to the point where there is a critical mass of client and server deployment, a process which takes time. the primary rationale for doing composite key exchange now is to > defend against retrospective attacks in case a quantum computer exists > in the future. In this setting, it isn't critically important to have > the PQ algorithm be the one we eventually land on, because each > connection is separately negotiated and as long as the PQ algorithm > has some security, you're getting benegit,. > > > In that case, would it make sense to take the next step with drafting an > intended standard for composite key exchanges (that is PQ > algorithm-agnostic)? If not, why not? > I think not, at least for TLS. The consensus of implementors seems to be that it's better to just cast composite algorithms as if they were new DH groups, so there's not a huge amount of leverage in a generic mechanism. -Ekr Carrick > > > > > On Dec 25, 2019, at 5:57 PM, Eric Rescorla wrote: > > On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle > wrote: > > How can it be true that it's too early to start developing a protocol > > for composite keys and signatures for Web PKI when Cloudflare and > > Google have already finished a round of experiments with composite key > > exchanges? Maybe I'm reading too much into it, but the existence of > > those experiments suggested to me that the need for composite/composite > > implementations was imminent. (I understand that the draft in question > > concerns signatures, not key exchanges, but apparently there isn't > > even a draft for the latter yet.) > > ISTM that these cases are pretty different, in a number of respects. > > First, the primary rationale for doing composite key exchange now is to > defend against retrospective attacks in case a quantum computer exists > in the future. In this setting, it isn't critically important to have > the PQ algorithm be the one we eventually land on, because each > connection is separately negotiated and as long as the PQ algorithm > has some security, you're getting benegit,. > > The primary rationale for doing PQ authentication now (or for that > matter composite authentication) is to be prepared for the day when QC > exists and we are therefore unable to rely on classical > algorithms. However, it's not useful to be prepared in that fashion > unless the algorithm that you are deploying is the one that is > eventually selected, because otherwise you just have to start over > once the selection is made. > > Moreover, in order to be truly prepared, what you need isn't > principally relying party deployment, but rather authenticating party > (in the case of the WebPKI, server-side) deployment. The reason for > this is that in the world where a QC exists, you don't have protection > until the relying party refuses to accept the classical credential > [0], and at present, any client which does so will effectively be > unable to communicate. And in order to make that happen, relying > parties will have to require a post-quantum algorithm (most likely as > a composite) and that's something I don't expect them to be willing to do > until there's widespread agreement on what that algorithm should be. > > > > If not now, when? After NIST crowns a winner? I don't see why it's > > necessary to wait that long given that the proposed solutions are > > algorithm-independent. And since the standardization process takes a > > while, won't waiting until then mean that there won't be a standard > > until after it's needed? > > No, i don't think so. > > For the reasons above, ISTM that real deployment will have to wait > until we have a selected algorithm. One could, as you suggest, deploy > some sort of multi-algorithm container, but IMO we will be far better > off just deploying new composite algorithms as if the were single > new algorithms, in the same way as we have done for key establishment. > > For this reason, I think we ought to wait until there is a consensus > PQ signature algorithm, at least for the WebPKI. > > -Ekr > > [0] This is why this kind of composite isn't helpful in the world > where a secret QC exists not. > > >> _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > > > --000000000000a76234059b2cae8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 10:45 AM Carri= ck Bartle <cbartle891@icloud.co= m> wrote:
it's not useful to be prep= ared in that fashion
unless the algorithm that you are deploying is the = one that is
eventually selected, because otherwise you just have to star= t over
once the selection is made.
Just to be specific, do you mean, for instance, all the certificate= s with the PQ algorithm that wasn't chosen would have to be revoked?

Probably not.

=
At a high level, there are two possible designs:

<= div>1. A certificate which has a composite signature in place of the classi= cal signature and thus cannot be validated by old clients.
2. A c= ertificate which has a PQ signature somehow attached in a way that it leave= s the classical signature valid (as in an extension).

<= div>In the former case, every server would need two certificates (one compo= site and one classical) and use signature_algorithms to distinguish which o= ne to use. Once clients stopped liking the old PQ algorithm, then those com= posite certificates would become irrelevant and just be unused. In the latt= er case, the certificates would continue to be valid and the client could j= ust ignore the PQ part of the signature.

What &quo= t;start over" means in this case is get to the point where there is a = critical mass of client and server deployment, a process which takes time.<= br>

<= div style=3D"overflow-wrap: break-word;">
the primary rationale for d= oing composite key exchange now is to
defend against retrospective attac= ks in case a quantum computer exists
in the future. In this setting, it = isn't critically important to have
the PQ algorithm be the one we ev= entually land on, because each
connection is separately negotiated and a= s long as the PQ algorithm
has some security, you're getting benegit= ,.

In that case, wo= uld it make sense to take the next step with drafting an intended standard = for composite key exchanges (that is PQ algorithm-agnostic)? If not, why no= t?

I think not, at least for TL= S. The consensus of implementors seems to be that it's better to just c= ast composite algorithms as if they were new DH groups, so there's not = a huge amount of leverage in a generic mechanism.

<= div>-Ekr

Carrick




On Dec = 25, 2019, at 5:57 PM, Eric Rescorla <ekr@rtfm.com> wrote:

<= div dir=3D"ltr">
On Mon, Dec 23, 2019 at 8:38 PM Carrick Ba= rtle <cbartle= 891@icloud.com> wrote:
> How can it be true= that it's too early to start developing a protocol
> for composi= te keys and signatures for Web PKI when Cloudflare and
> Google have = already finished a round of experiments with composite key
> exchange= s? Maybe I'm reading too much into it, but the existence of
> tho= se experiments suggested to me that the need for composite/composite
>= ; implementations was imminent. (I understand that the draft in question> concerns signatures, not key exchanges, but apparently there isn'= t
> even a draft for the latter yet.)

ISTM that these cases ar= e pretty different, in a number of respects.

First, the primary rati= onale for doing composite key exchange now is to
defend against retrospe= ctive attacks in case a quantum computer exists
in the future. In this s= etting, it isn't critically important to have
the PQ algorithm be th= e one we eventually land on, because each
connection is separately negot= iated and as long as the PQ algorithm
has some security, you're gett= ing benegit,.

The primary rationale for doing PQ authentication now = (or for that
matter composite authentication) is to be prepared for the = day when QC
exists and we are therefore unable to rely on classical
a= lgorithms. However, it's not useful to be prepared in that fashion
u= nless the algorithm that you are deploying is the one that is
eventually= selected, because otherwise you just have to start over
once the select= ion is made.

Moreover, in order to be truly prepared, what you need = isn't
principally relying party deployment, but rather authenticatin= g party
(in the case of the WebPKI, server-side) deployment. The reason = for
this is that in the world where a QC exists, you don't have prot= ection
until the relying party refuses to accept the classical credentia= l
[0], and at present, any client which does so will effectively be
u= nable to communicate. And in order to make that happen, relying
parties = will have to require a post-quantum algorithm (most likely as
a composit= e) and that's something I don't expect them to be willing to do
= until there's widespread agreement on what that algorithm should be.

> If not now, when? After NIST crowns a winner? I don't see= why it's
> necessary to wait that long given that the proposed s= olutions are
> algorithm-independent. And since the standardization p= rocess takes a
> while, won't waiting until then mean that there = won't be a standard
> until after it's needed?

No, i d= on't think so.

For the reasons above, ISTM that real deployment = will have to wait
until we have a selected algorithm. One could, as you = suggest, deploy
some sort of multi-algorithm container, but IMO we will = be far better
off just deploying new composite algorithms as if the were= single
new algorithms, in the same way as we have done for key establis= hment.

For this reason, I think we ought to wait until there is a co= nsensus
PQ signature algorithm, at least for the WebPKI.

-Ekr
=
[0] This is why this kind of composite isn't helpful in the worldwhere a secret QC exists not.


_______________________________________________
Secdispatch mailing list=
Secdispatch@i= etf.org
https://www.ietf.org/mailman/listinfo/secdispatch

--000000000000a76234059b2cae8a-- From nobody Thu Jan 2 11:19:55 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13081120103 for ; Thu, 2 Jan 2020 11:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 WhQxletSO6lc for ; Thu, 2 Jan 2020 11:19:51 -0800 (PST) Received: from mr85p00im-ztdg06011201.me.com (mr85p00im-ztdg06011201.me.com [17.58.23.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C941200CD for ; Thu, 2 Jan 2020 11:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1577992790; bh=rOseGqQWtVKlVFaxeuXTCTJma5EFPnooOweYaOHRp50=; h=From:Message-Id:Content-Type:Subject:Date:To; b=LhyAo+8eY2tkyZDjQYnSBmlKLo4eGMWp7Y4emQlHSSarr434xL4nsHrWYrQDjXtX/ OXjZWYTno1fPvloMMA2bIBo3XEjDOdWJTETYXVVamD3be+8erkzPRmApOXQ8kiwMcD Iz3hh38x8ORUS2gKOrS4oZwbDUggaTmoE/YvYJLSjohDm7N6KiSj1BO2sDdz3ffBXq esx8vHUqoTERMbAOdZYB42Q4O0fHDLU6Wi2+ieRTJDXpZIO4mCn3oQ0TOxDKcMU1Vl zV83pwaRxrBwrITSEFbKnjpYBZx9j8FhVWvAqkcWj7eWEE5v77izZLR+ZmN2ztbFof oqGKkbLm2CG/g== Received: from [17.230.160.114] (unknown [17.230.160.114]) by mr85p00im-ztdg06011201.me.com (Postfix) with ESMTPSA id 63FB1400A7D; Thu, 2 Jan 2020 19:19:50 +0000 (UTC) From: Carrick Bartle Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_40EA03CC-C47F-4B5C-BD51-3003BEBDE6DC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\)) Date: Thu, 2 Jan 2020 11:19:49 -0800 In-Reply-To: Cc: "Dr. Pala" , "Salz, Rich" , IETF SecDispatch , Stephen Farrell To: Eric Rescorla References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> X-Mailer: Apple Mail (2.3608.80.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-02_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2001020156 Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 19:19:53 -0000 --Apple-Mail=_40EA03CC-C47F-4B5C-BD51-3003BEBDE6DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > What "start over" means in this case is get to the point where there = is a critical mass of client and server deployment, a process which = takes time. I see. > I think not, at least for TLS. The consensus of implementors seems to = be that it's better to just cast composite algorithms as if they were = new DH groups, so there's not a huge amount of leverage in a generic = mechanism. My understanding is that the Cloudflare-Google implementation generated = two separate shared secrets. Also this draft references several = different "ad hoc" approaches in implementations: = https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01 = . Carrick > On Jan 2, 2020, at 10:50 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle > wrote: >> it's not useful to be prepared in that fashion >> unless the algorithm that you are deploying is the one that is >> eventually selected, because otherwise you just have to start over >> once the selection is made. >=20 > Just to be specific, do you mean, for instance, all the certificates = with the PQ algorithm that wasn't chosen would have to be revoked? >=20 > Probably not.=20 >=20 > At a high level, there are two possible designs: >=20 > 1. A certificate which has a composite signature in place of the = classical signature and thus cannot be validated by old clients. > 2. A certificate which has a PQ signature somehow attached in a way = that it leaves the classical signature valid (as in an extension). >=20 > In the former case, every server would need two certificates (one = composite and one classical) and use signature_algorithms to distinguish = which one to use. Once clients stopped liking the old PQ algorithm, then = those composite certificates would become irrelevant and just be unused. = In the latter case, the certificates would continue to be valid and the = client could just ignore the PQ part of the signature. >=20 > What "start over" means in this case is get to the point where there = is a critical mass of client and server deployment, a process which = takes time. >=20 >> the primary rationale for doing composite key exchange now is to >> defend against retrospective attacks in case a quantum computer = exists >> in the future. In this setting, it isn't critically important to have >> the PQ algorithm be the one we eventually land on, because each >> connection is separately negotiated and as long as the PQ algorithm >> has some security, you're getting benegit,. >=20 >=20 > In that case, would it make sense to take the next step with drafting = an intended standard for composite key exchanges (that is PQ = algorithm-agnostic)? If not, why not? >=20 > I think not, at least for TLS. The consensus of implementors seems to = be that it's better to just cast composite algorithms as if they were = new DH groups, so there's not a huge amount of leverage in a generic = mechanism. >=20 > -Ekr >=20 > Carrick >=20 >=20 >=20 >=20 >> On Dec 25, 2019, at 5:57 PM, Eric Rescorla > wrote: >>=20 >> On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle > wrote: >> > How can it be true that it's too early to start developing a = protocol >> > for composite keys and signatures for Web PKI when Cloudflare and >> > Google have already finished a round of experiments with composite = key >> > exchanges? Maybe I'm reading too much into it, but the existence of >> > those experiments suggested to me that the need for = composite/composite >> > implementations was imminent. (I understand that the draft in = question >> > concerns signatures, not key exchanges, but apparently there isn't >> > even a draft for the latter yet.) >>=20 >> ISTM that these cases are pretty different, in a number of respects. >>=20 >> First, the primary rationale for doing composite key exchange now is = to >> defend against retrospective attacks in case a quantum computer = exists >> in the future. In this setting, it isn't critically important to have >> the PQ algorithm be the one we eventually land on, because each >> connection is separately negotiated and as long as the PQ algorithm >> has some security, you're getting benegit,. >>=20 >> The primary rationale for doing PQ authentication now (or for that >> matter composite authentication) is to be prepared for the day when = QC >> exists and we are therefore unable to rely on classical >> algorithms. However, it's not useful to be prepared in that fashion >> unless the algorithm that you are deploying is the one that is >> eventually selected, because otherwise you just have to start over >> once the selection is made. >>=20 >> Moreover, in order to be truly prepared, what you need isn't >> principally relying party deployment, but rather authenticating party >> (in the case of the WebPKI, server-side) deployment. The reason for >> this is that in the world where a QC exists, you don't have = protection >> until the relying party refuses to accept the classical credential >> [0], and at present, any client which does so will effectively be >> unable to communicate. And in order to make that happen, relying >> parties will have to require a post-quantum algorithm (most likely as >> a composite) and that's something I don't expect them to be willing = to do >> until there's widespread agreement on what that algorithm should be. >>=20 >>=20 >> > If not now, when? After NIST crowns a winner? I don't see why it's >> > necessary to wait that long given that the proposed solutions are >> > algorithm-independent. And since the standardization process takes = a >> > while, won't waiting until then mean that there won't be a standard >> > until after it's needed? >>=20 >> No, i don't think so. >>=20 >> For the reasons above, ISTM that real deployment will have to wait >> until we have a selected algorithm. One could, as you suggest, deploy >> some sort of multi-algorithm container, but IMO we will be far better >> off just deploying new composite algorithms as if the were single >> new algorithms, in the same way as we have done for key = establishment. >>=20 >> For this reason, I think we ought to wait until there is a consensus >> PQ signature algorithm, at least for the WebPKI. >>=20 >> -Ekr >>=20 >> [0] This is why this kind of composite isn't helpful in the world >> where a secret QC exists not. >>=20 >>=20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch = --Apple-Mail=_40EA03CC-C47F-4B5C-BD51-3003BEBDE6DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
What "start over" means in this = case is get to the point where there is a critical mass of client and = server deployment, a process which takes = time.

I see.

I think not, at least for TLS. = The consensus of implementors seems to be that it's better to just cast = composite algorithms as if they were new DH groups, so there's not a = huge amount of leverage in a generic = mechanism.

My understanding is that the = Cloudflare-Google implementation generated two separate shared secrets. = Also this draft references several different "ad hoc" approaches in = implementations: https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01<= /a>.

Carrick


On Jan = 2, 2020, at 10:50 AM, Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle = <cbartle891@icloud.com> wrote:
it's not useful to be prepared in that fashion
unless the algorithm that you are deploying is the one that = is
eventually selected, because otherwise you just have to = start over
once the selection is = made.

Just to be specific, do you mean, for instance, all the = certificates with the PQ algorithm that wasn't chosen would have to be = revoked?

Probably not. 

At a high level, there = are two possible designs:

1. A certificate which has a composite signature in place of = the classical signature and thus cannot be validated by old = clients.
2. A certificate which has a PQ signature = somehow attached in a way that it leaves the classical signature valid = (as in an extension).

In the former case, every server would need two certificates = (one composite and one classical) and use signature_algorithms to = distinguish which one to use. Once clients stopped liking the old PQ = algorithm, then those composite certificates would become irrelevant and = just be unused. In the latter case, the certificates would continue to = be valid and the client could just ignore the PQ part of the = signature.

What = "start over" means in this case is get to the point where there is a = critical mass of client and server deployment, a process which takes = time.

the primary rationale for doing composite key = exchange now is to
defend against retrospective attacks in = case a quantum computer exists
in the future. In this = setting, it isn't critically important to have
the PQ = algorithm be the one we eventually land on, because each
connection is separately negotiated and as long as the PQ = algorithm
has some security, you're getting = benegit,.

In that case, would it make sense to = take the next step with drafting an intended standard for composite key = exchanges (that is PQ algorithm-agnostic)? If not, why = not?

I think not, at least for TLS. The consensus of implementors = seems to be that it's better to just cast composite algorithms as if = they were new DH groups, so there's not a huge amount of leverage in a = generic mechanism.

-Ekr

Carrick




On Dec 25, 2019, at 5:57 PM, Eric Rescorla <ekr@rtfm.com> wrote:

On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle = <cbartle891@icloud.com> wrote:
> How can it be true that it's too early to start = developing a protocol
> for composite keys and = signatures for Web PKI when Cloudflare and
> Google = have already finished a round of experiments with composite key
> exchanges? Maybe I'm reading too much into it, but the = existence of
> those experiments suggested to me that = the need for composite/composite
> implementations was = imminent. (I understand that the draft in question
> = concerns signatures, not key exchanges, but apparently there isn't
> even a draft for the latter yet.)

ISTM that these cases are pretty different, in a number of = respects.

First, the primary rationale for = doing composite key exchange now is to
defend against = retrospective attacks in case a quantum computer exists
in = the future. In this setting, it isn't critically important to have
the PQ algorithm be the one we eventually land on, because = each
connection is separately negotiated and as long as = the PQ algorithm
has some security, you're getting = benegit,.

The primary rationale for doing = PQ authentication now (or for that
matter composite = authentication) is to be prepared for the day when QC
exists= and we are therefore unable to rely on classical
algorithms. However, it's not useful to be prepared in that = fashion
unless the algorithm that you are deploying is the = one that is
eventually selected, because otherwise you = just have to start over
once the selection is made.

Moreover, in order to be truly prepared, what = you need isn't
principally relying party deployment, but = rather authenticating party
(in the case of the WebPKI, = server-side) deployment. The reason for
this is that in = the world where a QC exists, you don't have protection
until= the relying party refuses to accept the classical credential
[0], and at present, any client which does so will = effectively be
unable to communicate. And in order to make = that happen, relying
parties will have to require a = post-quantum algorithm (most likely as
a composite) and = that's something I don't expect them to be willing to do
until there's widespread agreement on what that algorithm = should be.


> If not now, = when? After NIST crowns a winner? I don't see why it's
> = necessary to wait that long given that the proposed solutions are
> algorithm-independent. And since the standardization = process takes a
> while, won't waiting until then mean = that there won't be a standard
> until after it's = needed?

No, i don't think so.

For the reasons above, ISTM that real = deployment will have to wait
until we have a selected = algorithm. One could, as you suggest, deploy
some sort of = multi-algorithm container, but IMO we will be far better
off= just deploying new composite algorithms as if the were single
new algorithms, in the same way as we have done for key = establishment.

For this reason, I think we = ought to wait until there is a consensus
PQ signature = algorithm, at least for the WebPKI.

-Ekr

[0] This is why this kind of composite isn't = helpful in the world
where a secret QC exists not.


__________________________= _____________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
= --Apple-Mail=_40EA03CC-C47F-4B5C-BD51-3003BEBDE6DC-- From nobody Thu Jan 2 12:12:09 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7E512004D for ; Thu, 2 Jan 2020 12:12: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vz6dmN4v8Zn for ; Thu, 2 Jan 2020 12:12:05 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17C112012E for ; Thu, 2 Jan 2020 12:12:04 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id y6so33840474lji.0 for ; Thu, 02 Jan 2020 12:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bKjCuQAl6v/yET1LW1RYGKrWgx5w0wp5uSdbHGc+GFM=; b=Tldn1VPEmZyiJ7e3isXnUMBdibFcm2tDoB81cG8bhqKsk+KL6zKwIDHkc3ekr/GVwM SsOFEb9iH4hAbRYpESSF4Trj9vDg9Tk06+n10YzefsIjIaL3mCt1cvP4Nnlsf/ejwI04 bd2KWJdGF2rYqtVMsvG14prQI0o4+kI7ZLCUh5QKfWLjyIJC5JTto9j52vk2bnjRD3zU CD3+5kG0uz6SAW3XtS93GCx7K2vICfVZL/F5pxuezz0b9wKTvZSFoQ5tYAEBjdK3Nj5/ WOElCuQ7kZU0AuaNz/IPyFbvddV/V/RcV5bHT68Oos+ClTQHqUeB+EY/9gfPCrWAwSiu 50qA== 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=bKjCuQAl6v/yET1LW1RYGKrWgx5w0wp5uSdbHGc+GFM=; b=OhWbk75OcrrYhNYsltbBoPb3hs4aeYgxF9Wu7jiAxGl0pHz6ytOwI7L4EMPW72XgEc j0QBWAuqar/69P8MaIa80ecGtBgeKylW5oysTErZ0AAIpA4IO4TJQLaVX/raWgYw42EW jXo9huDIrhfSqZP1WYLDU7kgG31SINByWXKvoYOc1WyFzQVzuHzLdRjqSYVrDcDHwmbw HxMcC5PpKlURYNl0BH7SxT7NxkD6+zE1ZO2LpA6hLIsmeL1GSuVkTsJ411DqYZaSQRj0 rE4YFfEDCYjhSXmeCHouFw4GoMwC1TV+QZL623JvAQV+msWbwW25AmXwzqJdBWDmyQ19 tPtA== X-Gm-Message-State: APjAAAV93WI27m1XgUQF7He7Vy+UBLX35amna3cG4u8VULXOUHZYEquK xJUY2XwZgmrFYUnV5Vjj2Yng8mrHqSsXSiXFDog77g== X-Google-Smtp-Source: APXvYqxLsaOd0aDASLSIPF03L5/1icGyxVlmByvLKCekRk11mzXvcG67U+AnsfdZqh19ejrgHYlvV84ox3sUc7c+b04= X-Received: by 2002:a2e:9008:: with SMTP id h8mr50855007ljg.217.1577995921567; Thu, 02 Jan 2020 12:12:01 -0800 (PST) MIME-Version: 1.0 References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> In-Reply-To: From: Eric Rescorla Date: Thu, 2 Jan 2020 12:11:24 -0800 Message-ID: To: Carrick Bartle Cc: "Dr. Pala" , "Salz, Rich" , IETF SecDispatch , Stephen Farrell Content-Type: multipart/alternative; boundary="0000000000005cc5a1059b2dce0c" Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 20:12:08 -0000 --0000000000005cc5a1059b2dce0c Content-Type: text/plain; charset="UTF-8" On Thu, Jan 2, 2020 at 11:19 AM Carrick Bartle wrote: > What "start over" means in this case is get to the point where there is a > critical mass of client and server deployment, a process which takes time. > > > I see. > > I think not, at least for TLS. The consensus of implementors seems to be > that it's better to just cast composite algorithms as if they were new DH > groups, so there's not a huge amount of leverage in a generic mechanism. > > > My understanding is that the Cloudflare-Google implementation generated > two separate shared secrets. Also this draft references several different > "ad hoc" approaches in implementations: > https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01. > Well, yes, but on the wire it's packaged as a single group and key share. https://blog.cloudflare.com/the-tls-post-quantum-experiment/ -Ekr > Carrick > > > On Jan 2, 2020, at 10:50 AM, Eric Rescorla wrote: > > > > On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle > wrote: > >> it's not useful to be prepared in that fashion >> unless the algorithm that you are deploying is the one that is >> eventually selected, because otherwise you just have to start over >> once the selection is made. >> >> >> Just to be specific, do you mean, for instance, all the certificates with >> the PQ algorithm that wasn't chosen would have to be revoked? >> > > Probably not. > > At a high level, there are two possible designs: > > 1. A certificate which has a composite signature in place of the classical > signature and thus cannot be validated by old clients. > 2. A certificate which has a PQ signature somehow attached in a way that > it leaves the classical signature valid (as in an extension). > > In the former case, every server would need two certificates (one > composite and one classical) and use signature_algorithms to distinguish > which one to use. Once clients stopped liking the old PQ algorithm, then > those composite certificates would become irrelevant and just be unused. In > the latter case, the certificates would continue to be valid and the client > could just ignore the PQ part of the signature. > > What "start over" means in this case is get to the point where there is a > critical mass of client and server deployment, a process which takes time. > > the primary rationale for doing composite key exchange now is to >> defend against retrospective attacks in case a quantum computer exists >> in the future. In this setting, it isn't critically important to have >> the PQ algorithm be the one we eventually land on, because each >> connection is separately negotiated and as long as the PQ algorithm >> has some security, you're getting benegit,. >> >> >> In that case, would it make sense to take the next step with drafting an >> intended standard for composite key exchanges (that is PQ >> algorithm-agnostic)? If not, why not? >> > > I think not, at least for TLS. The consensus of implementors seems to be > that it's better to just cast composite algorithms as if they were new DH > groups, so there's not a huge amount of leverage in a generic mechanism. > > -Ekr > > Carrick >> >> >> >> >> On Dec 25, 2019, at 5:57 PM, Eric Rescorla wrote: >> >> On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle >> wrote: >> > How can it be true that it's too early to start developing a protocol >> > for composite keys and signatures for Web PKI when Cloudflare and >> > Google have already finished a round of experiments with composite key >> > exchanges? Maybe I'm reading too much into it, but the existence of >> > those experiments suggested to me that the need for composite/composite >> > implementations was imminent. (I understand that the draft in question >> > concerns signatures, not key exchanges, but apparently there isn't >> > even a draft for the latter yet.) >> >> ISTM that these cases are pretty different, in a number of respects. >> >> First, the primary rationale for doing composite key exchange now is to >> defend against retrospective attacks in case a quantum computer exists >> in the future. In this setting, it isn't critically important to have >> the PQ algorithm be the one we eventually land on, because each >> connection is separately negotiated and as long as the PQ algorithm >> has some security, you're getting benegit,. >> >> The primary rationale for doing PQ authentication now (or for that >> matter composite authentication) is to be prepared for the day when QC >> exists and we are therefore unable to rely on classical >> algorithms. However, it's not useful to be prepared in that fashion >> unless the algorithm that you are deploying is the one that is >> eventually selected, because otherwise you just have to start over >> once the selection is made. >> >> Moreover, in order to be truly prepared, what you need isn't >> principally relying party deployment, but rather authenticating party >> (in the case of the WebPKI, server-side) deployment. The reason for >> this is that in the world where a QC exists, you don't have protection >> until the relying party refuses to accept the classical credential >> [0], and at present, any client which does so will effectively be >> unable to communicate. And in order to make that happen, relying >> parties will have to require a post-quantum algorithm (most likely as >> a composite) and that's something I don't expect them to be willing to do >> until there's widespread agreement on what that algorithm should be. >> >> >> > If not now, when? After NIST crowns a winner? I don't see why it's >> > necessary to wait that long given that the proposed solutions are >> > algorithm-independent. And since the standardization process takes a >> > while, won't waiting until then mean that there won't be a standard >> > until after it's needed? >> >> No, i don't think so. >> >> For the reasons above, ISTM that real deployment will have to wait >> until we have a selected algorithm. One could, as you suggest, deploy >> some sort of multi-algorithm container, but IMO we will be far better >> off just deploying new composite algorithms as if the were single >> new algorithms, in the same way as we have done for key establishment. >> >> For this reason, I think we ought to wait until there is a consensus >> PQ signature algorithm, at least for the WebPKI. >> >> -Ekr >> >> [0] This is why this kind of composite isn't helpful in the world >> where a secret QC exists not. >> >> >>> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> >> > --0000000000005cc5a1059b2dce0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 11:19 AM Carri= ck Bartle <cbartle891@icloud.co= m> wrote:
<= div class=3D"gmail_quote">
What "start over" means in this ca= se is get to the point where there is a critical mass of client and server = deployment, a process which takes time.
=
I see.

I think not, at least for TLS. The consensus = of implementors seems to be that it's better to just cast composite alg= orithms as if they were new DH groups, so there's not a huge amount of = leverage in a generic mechanism.

My understanding is that the Cloudflare-Google implementation gener= ated two separate shared secrets. Also this draft references several differ= ent "ad hoc" approaches in implementations:=C2=A0https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01.
=

Well, yes, but on the wire it's = packaged as a single group and key share.


-Ekr


Ca= rrick


On Jan 2, 2020,= at 10:50 AM, Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle <cbartle891@icloud.com> wrote:=
it's= not useful to be prepared in that fashion
unless the algorithm that you= are deploying is the one that is
eventually selected, because otherwise= you just have to start over
once the selection is made.

Just to be specific, do you mean, for instanc= e, all the certificates with the PQ algorithm that wasn't chosen would = have to be revoked?

Probably not.=C2=A0

At a high level, there are two= possible designs:

1. A certificate which has a co= mposite signature in place of the classical signature and thus cannot be va= lidated by old clients.
2. A certificate which has a PQ signature= somehow attached in a way that it leaves the classical signature valid (as= in an extension).

In the former case, every serve= r would need two certificates (one composite and one classical) and use sig= nature_algorithms to distinguish which one to use. Once clients stopped lik= ing the old PQ algorithm, then those composite certificates would become ir= relevant and just be unused. In the latter case, the certificates would con= tinue to be valid and the client could just ignore the PQ part of the signa= ture.

What "start over" means in this ca= se is get to the point where there is a critical mass of client and server = deployment, a process which takes time.

=
the primary rationale fo= r doing composite key exchange now is to
defend against retrospective at= tacks in case a quantum computer exists
in the future. In this setting, = it isn't critically important to have
the PQ algorithm be the one we= eventually land on, because each
connection is separately negotiated an= d as long as the PQ algorithm
has some security, you're getting bene= git,.

In that case,= would it make sense to take the next step with drafting an intended standa= rd for composite key exchanges (that is PQ algorithm-agnostic)? If not, why= not?

I think not, at least for= TLS. The consensus of implementors seems to be that it's better to jus= t cast composite algorithms as if they were new DH groups, so there's n= ot a huge amount of leverage in a generic mechanism.

-Ekr

Carrick



<= br>
On Dec 25, 2019, at 5:57 PM, Eric Rescorl= a <ekr@rtfm.com>= ; wrote:

O= n Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle <cbartle891@icloud.com> wrote:
> How can it be true that it's too early to start = developing a protocol
> for composite keys and signatures for Web PKI= when Cloudflare and
> Google have already finished a round of experi= ments with composite key
> exchanges? Maybe I'm reading too much = into it, but the existence of
> those experiments suggested to me tha= t the need for composite/composite
> implementations was imminent. (I= understand that the draft in question
> concerns signatures, not key= exchanges, but apparently there isn't
> even a draft for the lat= ter yet.)

ISTM that these cases are pretty different, in a number of= respects.

First, the primary rationale for doing composite key exch= ange now is to
defend against retrospective attacks in case a quantum co= mputer exists
in the future. In this setting, it isn't critically im= portant to have
the PQ algorithm be the one we eventually land on, becau= se each
connection is separately negotiated and as long as the PQ algori= thm
has some security, you're getting benegit,.

The primary r= ationale for doing PQ authentication now (or for that
matter composite a= uthentication) is to be prepared for the day when QC
exists and we are t= herefore unable to rely on classical
algorithms. However, it's not u= seful to be prepared in that fashion
unless the algorithm that you are d= eploying is the one that is
eventually selected, because otherwise you j= ust have to start over
once the selection is made.

Moreover, in o= rder to be truly prepared, what you need isn't
principally relying p= arty deployment, but rather authenticating party
(in the case of the Web= PKI, server-side) deployment. The reason for
this is that in the world w= here a QC exists, you don't have protection
until the relying party = refuses to accept the classical credential
[0], and at present, any clie= nt which does so will effectively be
unable to communicate. And in order= to make that happen, relying
parties will have to require a post-quantu= m algorithm (most likely as
a composite) and that's something I don&= #39;t expect them to be willing to do
until there's widespread agree= ment on what that algorithm should be.


> If not now, when? Af= ter NIST crowns a winner? I don't see why it's
> necessary to= wait that long given that the proposed solutions are
> algorithm-ind= ependent. And since the standardization process takes a
> while, won&= #39;t waiting until then mean that there won't be a standard
> un= til after it's needed?

No, i don't think so.

For the = reasons above, ISTM that real deployment will have to wait
until we have= a selected algorithm. One could, as you suggest, deploy
some sort of mu= lti-algorithm container, but IMO we will be far better
off just deployin= g new composite algorithms as if the were single
new algorithms, in the = same way as we have done for key establishment.

For this reason, I t= hink we ought to wait until there is a consensus
PQ signature algorithm,= at least for the WebPKI.

-Ekr

[0] This is why this kind of c= omposite isn't helpful in the world
where a secret QC exists not.


_______________________________________________=
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailma= n/listinfo/secdispatch

--0000000000005cc5a1059b2dce0c-- From nobody Thu Jan 2 17:13:48 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F289C12006F for ; Thu, 2 Jan 2020 17:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brT1GOGbbzUI for ; Thu, 2 Jan 2020 17:13:45 -0800 (PST) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 B101812006B for ; Thu, 2 Jan 2020 17:13:45 -0800 (PST) Received: by mail-qv1-xf2d.google.com with SMTP id u1so14840603qvk.13 for ; Thu, 02 Jan 2020 17:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=61eD2Uttkn8qN/2yzTnuL/Djw2YYPhjMwuDkVoc0BZI=; b=tZZoSjAxL1Me8NtD2UQqOhkBx3HQsUysYG4LZ9dCfdbRbBOWmJuEktc0XRnAEFFc84 6b/e0Gc2jSijOAKL/9DEzLzJNrn+AcQvO5bNT8jlDBaxWMwtwYRM7VYO4LMkMcITsPDK KtgfZnxu9dInOU4hSoA5CboZZpJ+Z3Wt5Ufn3wM/a4tor3sIMp07XHmDEUzKUjEHNvyt mBtHLDSa55U5EaxNan9ffTcNwPl0W0PfprdL1fFYuoz5+D/HfivTIKkl/nVx5LJPSn/Z p08gXjky24mmdX4+rcU15o6ddUGG6lr8yAry3Tre7BAfVp4hJLr7bbwXAhh52Jpnueiz oGZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=61eD2Uttkn8qN/2yzTnuL/Djw2YYPhjMwuDkVoc0BZI=; b=R+AByhRnVygAIutb2P2dDN/awANJr/0SPvTIcMjyEYPRNmj+D94gd2voCIS72Vq+EJ wR4qf2V4IJnU/M09FcWhRr5QHtW1/4pKbRSkCZfrxWEaAUADb6JYc1wbiWFv2Jx5UCFh 1IVwFs6uYwlllZF0IcV8vmT/wKZdyYuRUSVx+PPxLFHUSPLf3OJ/16khffTGyOv6zdoc D4qXKKzX2To/AtX0XopTiOq9Sk/Yh/AezWfcGtbS0aTFt47sOlPl+ypMaiONaMJ8bWXb e/8FuznyzuwgyJZ8pEM0Vk9ZqPYYfLC3nrPcI0hmYE+CgVcS9Uuv+2sZLl96GTCFVl7P 7sLw== X-Gm-Message-State: APjAAAV0fBKTLHJzt3M1k6pw3b2u2saX8m1+UtDv9DEA4Mt4sL39QjlB SgleEnjkf6ZUcOjz4Mt4TWQ= X-Google-Smtp-Source: APXvYqwgUG3DZMVu9PmAOaWeafBhbJGvEuxNpkwWvjYynpmka/vHQGzsFQS9OQ1N372EOQCWc4Ib9Q== X-Received: by 2002:a05:6214:1150:: with SMTP id b16mr66318474qvt.71.1578014024923; Thu, 02 Jan 2020 17:13:44 -0800 (PST) Received: from laptop-ethernet.coleridge (CPE881fa12cf37b-CMa84e3fc93e50.cpe.net.cable.rogers.com. [99.250.203.26]) by smtp.gmail.com with ESMTPSA id n129sm15771669qkf.64.2020.01.02.17.13.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jan 2020 17:13:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Douglas Stebila In-Reply-To: Date: Thu, 2 Jan 2020 20:13:42 -0500 Cc: Carrick Bartle , "Dr. Pala" , "Salz, Rich" , IETF SecDispatch , Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: <8EB3BE1E-44A0-4440-A62B-AEA38406E2E2@gmail.com> References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 01:13:47 -0000 On Jan 2, 2020, at 1:50 PM, Eric Rescorla wrote: >=20 > I think not, at least for TLS. The consensus of implementors seems to = be that it's better to just cast composite algorithms as if they were = new DH groups, so there's not a huge amount of leverage in a generic = mechanism. We'll soon be pushing a revision of = https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01 that = focuses on doing composite algorithms as new DH groups. Douglas From nobody Wed Jan 8 08:26:32 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998FD12084A for ; Wed, 8 Jan 2020 08:26:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYVJMdWcZxUS for ; Wed, 8 Jan 2020 08:26:24 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB54120152 for ; Wed, 8 Jan 2020 08:26:24 -0800 (PST) IronPort-SDR: 1f4D2lSqDxxz/DPpiaoQXqi4x1znKVqFUgeubevhJ+qCO++FES6EsNnzhdk1hv4fQBkU9uXxM5 bpe2It0MudqA== X-IronPort-AV: E=Sophos;i="5.69,410,1571720400"; d="scan'208,217";a="7296963" Received: from pmspex04.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.51]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 08 Jan 2020 10:26:23 -0600 Received: from PMSPEX04.corporate.datacard.com (192.168.211.51) by PMSPEX04.corporate.datacard.com (192.168.211.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Jan 2020 10:26:23 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (172.28.1.8) by PMSPEX04.corporate.datacard.com (192.168.211.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Jan 2020 10:26:23 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cMXl16IPQoOAGI/fP1/4H1HDrjWmDYH9to8tBAh5614wG0ijsznWGroO7Pj78EW5J2icdA+eN/PglrpSqUNRn+EwJpthGBxKuPKidqmqX0gfQH1L4zda4TGPCbVzZ/3TZRVZy7PNUol1n5twxMg8i+FURXKJAhbgmdk/viwkjlH7s+RCAOXaorwmsMWtkQMWDsrUEVZkaGmSYEYcl63A1RIAM0G7PIRUtZ7AQExo5yQKWnp/Yn+wPnftEqzDDnd8UV2984aOvSp/IxYH0wBJkEmOVq8CBOd5yzhsdqomnZWx52YdN3FfUtydrEowaJwDmEo1sBlhTNFDq5NguLOrsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SpERIisgww2Fakx2jzsFV7MAQtlepMg2dzZ74mMUEt0=; b=EFHQgt/MDl5Pyl8Op7dcEfB6H/daGYAO9HwWe8gdT3Lyc0T0FBA5jDPXcZN0gfWQNmEQ9uTKG0ShQqXhqzyOeA8LyBPTwRQpVCozrIraZxE0k5eMTKH5LE6ymkxn4LntGB+rUIDBXAaiWXRo2TwBqNeTwmZByb1B8xC3TkjwCnZ/GTDntnaS1uXXSuJymlQkjYNhbphGXcdQFM/ibhjcXv/tHXL7Ac7bl297p7ZhBMhRdlkFBDBoxMca2d9JjUqJTKaADjlF/Sn2z+AEflF8J+4IXOEkwWMmGjCr1l5czyrOW5xnc6UUTqdSewDDZRq69S4kHmLJ3QwrjshOzjJtZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SpERIisgww2Fakx2jzsFV7MAQtlepMg2dzZ74mMUEt0=; b=admLozgIWjJLX42c1u5z3gh+WFPQLM6WQn6XjsL6Rq4eVbe78Z3r2/M2xw/xauNh+/Q7+hLmiqUajeqx0A5rKU0sJPxdr0wQAhgw5qios860RlzE1CxhEL6bKPg3Vpr3uEWgRWKzffOjbT8l3oy9OUPultQNbcLD6d6vPQlSCUE= Received: from DM6PR11MB3883.namprd11.prod.outlook.com (10.255.61.32) by DM6PR11MB4153.namprd11.prod.outlook.com (10.255.61.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 8 Jan 2020 16:26:21 +0000 Received: from DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392]) by DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392%6]) with mapi id 15.20.2602.017; Wed, 8 Jan 2020 16:26:21 +0000 From: Mike Ounsworth To: Eric Rescorla , Carrick Bartle CC: "Dr. Pala" , "Salz, Rich" , "IETF SecDispatch" , Stephen Farrell Thread-Topic: [EXTERNAL]Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( Thread-Index: AQHVn3TqmuwoAaKifk6F5voq4PihRqeTq78AgDU9ZQCAAveOgIAMGfaAgAABkgCAAAgPgIAADmoAgAkfdvA= Date: Wed, 8 Jan 2020 16:26:21 +0000 Message-ID: References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [204.124.81.102] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 987358e8-5925-4143-1415-08d794577f7f x-ms-traffictypediagnostic: DM6PR11MB4153: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(376002)(366004)(346002)(51444003)(189003)(199004)(71200400001)(66946007)(66556008)(66476007)(66446008)(76116006)(64756008)(2906002)(5660300002)(55016002)(316002)(81166006)(81156014)(4326008)(9686003)(478600001)(186003)(966005)(8936002)(110136005)(52536014)(7696005)(54906003)(26005)(8676002)(86362001)(33656002)(53546011)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB4153; H:DM6PR11MB3883.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: z2rGvKVhkS8DoWuHTo6+8OWRs3SXc6FINBo5LQAK4So0vR/uwL0BykEvzMBQhpje4jWSQF5Q2NEm5pvOZRWo+cJBDwEwU4VR6Y+4vA00Pj2HmSUT3W6CqMU5GsOLlLvldLgNmbxOYYcjNlvS7XTt638lBBLn1z9ZvD6khOnii6hdjzfj3T8v0hL279SIKMc0QCHg05SznxBhFR+y4Y6U89KtHi80ihnOsjzy0oyjz5hQTDw6Hkn3sEVrRafxGBMom6YE+m7Y95RSnGELPBehEh+gCcyxvg5uYgXE9UqyxpuSUnkYcuB4keaTZPRCAFrFtw70SKEV3wQnQcSODth0SUh6G1N/o8Mx7BKO8NWzBcbZ7BNdrTiOeZKjBXgEzUwWHLH2CtrdGJBr+YV51H2NzNKnwIlDHOGTnUySTwne9C7dMTKE7z5aT+tPZ81TmdvV1o1qAd4X9HaGdrp8LedP+x7k9x1QXSFyz72TEbT+ZjBmsV9+xW0EvwxMXjwR9cMKdHbNZfmCMpxo6syQVC4ml9OfK5yOLe9Y7OQcvXE4Dfk4siie4MiGdbNAhsh5MzI6 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB38835E0C6C931C9E9BE676689B3E0DM6PR11MB3883namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 987358e8-5925-4143-1415-08d794577f7f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 16:26:21.6815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IYCcp1jmGe8XMsMXN8FJK/zQ/wyQjoVeOi0XCq4V5KGxwY6pY+rQlArc/B38zxhatWs4kOTZZy9oe8qL+BdCMD+9B4kLt6Kvsq54qwln8iqxflJVQe1BaW5mIazNuZmH X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4153 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla ( X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 16:26:28 -0000 --_000_DM6PR11MB38835E0C6C931C9E9BE676689B3E0DM6PR11MB3883namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RWtyIHNhaWQ6DQoNCkluIHRoZSBmb3JtZXIgY2FzZSwgZXZlcnkgc2VydmVyIHdvdWxkIG5lZWQg dHdvIGNlcnRpZmljYXRlcyAob25lIGNvbXBvc2l0ZSBhbmQgb25lIGNsYXNzaWNhbCkgYW5kIHVz ZSBzaWduYXR1cmVfYWxnb3JpdGhtcyB0byBkaXN0aW5ndWlzaCB3aGljaCBvbmUgdG8gdXNlLg0K DQpJIGFncmVlIHdpdGggeW91ciBjb25jbHVzaW9uIGFib3V0IGNvbXBvc2l0ZSBicmVha2luZyBi YWNrd2FyZHMgY29tcGF0aWJpbGl0eS4NCg0KVGhhdCBzYWlkLCBJIGNhdXRpb24gdXMgYWdhaW5z dCB0aGlua2luZyBhYm91dCB0aGlzIHByb2JsZW0gb25seSBpbiB0ZXJtcyBvZiBhIHNpbmdsZSB1 c2UtY2FzZSBvciBwcm90b2NvbCAoVExTIGluIHRoaXMgY2FzZSkuICBJIHdhbnQgdG8ga2VlcCB0 aGlzIGRpc2N1c3Npb24gY29uc2lkZXJpbmcgY2VydGlmaWNhdGUgdXNlLWNhc2VzIHRoYXQgZG9u 4oCZdCBoYXZlIGFsZ29yaXRobSBuZWdvdGlhdGlvbiBtZWNoYW5pc21zLCBmb3IgZXhhbXBsZSBj b2RlLXNpZ25pbmcsIFMvTUlNRSwgUEtJIHNtYXJ0IGNhcmRzLCBmaWxlIGVuY3J5cHRpb24sIHdo YXRldmVyIHVzZXMgY2VydGlmaWNhdGVzIGluIGEgd2F5IHRoYXQgaXNu4oCZdCDigJxvbmxpbmXi gJ0uICBJIHdvdWxkIGxvdmUgdG8gc2VlIHRoZSBJRVRGIHByb3ZpZGUgYSBzb2x1dGlvbiB0aGF0 IGFwcGxpZXMgdG8gY2VydGlmaWNhdGVzIGFuZCBzaWduYXR1cmVzIGluIGdlbmVyYWwsIHJhdGhl ciB0aGFuIHB1bnRpbmcgdGhpcyBwcm9ibGVtIHRvIGVhY2ggcHJvdG9jb2wgZGVzaWduIHRlYW0g dG8gc29sdmUgaW5kZXBlbmRlbnRseS4NCg0KDQpUaGUgcHJpbWFyeSByYXRpb25hbGUgZm9yIGRv aW5nIFBRIGF1dGhlbnRpY2F0aW9uIG5vdyAob3IgZm9yIHRoYXQNCm1hdHRlciBjb21wb3NpdGUg YXV0aGVudGljYXRpb24pIGlzIHRvIGJlIHByZXBhcmVkIGZvciB0aGUgZGF5IHdoZW4gUUMNCmV4 aXN0cyBhbmQgd2UgYXJlIHRoZXJlZm9yZSB1bmFibGUgdG8gcmVseSBvbiBjbGFzc2ljYWwNCmFs Z29yaXRobXMuIEhvd2V2ZXIsIGl0J3Mgbm90IHVzZWZ1bCB0byBiZSBwcmVwYXJlZCBpbiB0aGF0 IGZhc2hpb24NCnVubGVzcyB0aGUgYWxnb3JpdGhtIHRoYXQgeW91IGFyZSBkZXBsb3lpbmcgaXMg dGhlIG9uZSB0aGF0IGlzDQpldmVudHVhbGx5IHNlbGVjdGVkLCBiZWNhdXNlIG90aGVyd2lzZSB5 b3UganVzdCBoYXZlIHRvIHN0YXJ0IG92ZXINCm9uY2UgdGhlIHNlbGVjdGlvbiBpcyBtYWRlLg0K DQpUaGlzIGNvbmNsdXNpb24g4oCTIHRoYXQgeW914oCZcmUgb25seSBnZXR0aW5nIHNlY3VyaXR5 IHZhbHVlIG9uY2UgYSBQUSBleGlzdHMsIGFuZCBhbnkgYWxnIGltcGxlbWVudGF0aW9uIHdlIGNo b3NlIHRvZGF5IHdpbGwgbGlrZWx5IGJlIG9ic29sZXRlIGJ5IHRoZW4gLS0gaXMgcHJvYmFibHkg cmlnaHQgZm9yIGJyb3dzZXJzLCBidXQgd2hhdCBhYm91dCBJb1QgZGV2aWNlcyB2YWxpZGF0aW5n IHRoZWlyIGZpcm13YXJlIHNpZ25hdHVyZSBvbiBib290PyBPciBQS0kgc21hcnRjYXJkcz8gIE9y IGxlZ2FsIGNvbnRyYWN0cyBzaWduZWQgdW5kZXIgZUlEQVM/ICBUb2RheSB3ZSBhcmUgY3JlYXRp bmcgY2VydGlmaWNhdGVzIGFuZCBzaWduZWQgZGF0YSBvYmplY3RzIHRoYXQgd2lsbCBvdXRsaXZl IHRoZSBhZHZlbnQgb2YgYSBRQy4gIEkgdGhpbmsgdGhhdCBibHVycyBjbG9zZXIgdG8gdGhlIOKA nHJldHJvc3BlY3RpdmUgYXR0YWNr4oCdIHNjZW5hcmlvIHRoYXQgeW91IHVzZWQgZm9yIG1vdGl2 YXRpbmcgY29tcG9zaXRlIGtleSBleGNoYW5nZS4NCg0KV2hpbGUgSeKAmW0gYXdhcmUgdGhhdCBJ 4oCZbSB1c2luZyBtb3RpdmF0aW5nIGV4YW1wbGVzIGZyb20gb3V0c2lkZSB0aGUgSUVURiwgSSB0 aGluayB3ZSBoYXZlIGFuIG9wcG9ydHVuaXR5IHRvIGRlZmluZSBhIHN0YW5kYXJkIHRoYXQgaXMg Z2VuZXJpYyBmb3IgYWxsIChvciBhdCBsZWFzdCBtb3N0KSBjZXJ0aWZpY2F0ZSB1c2UtY2FzZXMu ICBMZXTigJlzIGRvIHRoZSBkZWJhdGUgaGVyZSBhYm91dCBjYXJyeWluZyBtdWx0aXBsZSBzaWdu YXR1cmVzIGFuZCB0aGUgc2VtYW50aWNzIG9mIHZhbGlkYXRpbmcgaXQsIHJhdGhlciB0aGFuIHB1 c2hpbmcgaXQgb3V0IHRvIGVhY2ggcHJvdG9jb2wgZGVzaWduIHRlYW0gdG8gZGViYXRlIGluZGVw ZW5kZW50bHkuDQoNCg0KLS0tDQpNaWtlIE91bnN3b3J0aCB8IE9mZmljZTogKzEgKDYxMykgMjcw LTI4NzMNCg0KRnJvbTogU2VjZGlzcGF0Y2ggPHNlY2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc+ IE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBKYW51YXJ5IDIsIDIwMjAgMjoxMSBQ TQ0KVG86IENhcnJpY2sgQmFydGxlIDxjYmFydGxlODkxQGljbG91ZC5jb20+DQpDYzogRHIuIFBh bGEgPG1hZHdvbGZAb3BlbmNhLm9yZz47IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+OyBJ RVRGIFNlY0Rpc3BhdGNoIDxzZWNkaXNwYXRjaEBpZXRmLm9yZz47IFN0ZXBoZW4gRmFycmVsbCA8 c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4NClN1YmplY3Q6IFtFWFRFUk5BTF1SZTogW1NlY2Rp c3BhdGNoXSBDbGFyaWZpY2F0aW9uIFF1ZXN0aW9uIGZvciB0aGUgQ29tbWVudCBmcm9tIEVyaWMg UmVzY29ybGEgKA0KDQpXQVJOSU5HOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgb3V0c2lkZSBvZiBF bnRydXN0IERhdGFjYXJkLg0KRE8gTk9UIENMSUNLIGxpbmtzIG9yIGF0dGFjaG1lbnRzIHVubGVz cyB5b3UgdHJ1c3QgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQpPbiBUaHUsIEphbiAyLCAyMDIwIGF0 IDExOjE5IEFNIENhcnJpY2sgQmFydGxlIDxjYmFydGxlODkxQGljbG91ZC5jb208bWFpbHRvOmNi YXJ0bGU4OTFAaWNsb3VkLmNvbT4+IHdyb3RlOg0KV2hhdCAic3RhcnQgb3ZlciIgbWVhbnMgaW4g dGhpcyBjYXNlIGlzIGdldCB0byB0aGUgcG9pbnQgd2hlcmUgdGhlcmUgaXMgYSBjcml0aWNhbCBt YXNzIG9mIGNsaWVudCBhbmQgc2VydmVyIGRlcGxveW1lbnQsIGEgcHJvY2VzcyB3aGljaCB0YWtl cyB0aW1lLg0KDQpJIHNlZS4NCg0KSSB0aGluayBub3QsIGF0IGxlYXN0IGZvciBUTFMuIFRoZSBj b25zZW5zdXMgb2YgaW1wbGVtZW50b3JzIHNlZW1zIHRvIGJlIHRoYXQgaXQncyBiZXR0ZXIgdG8g anVzdCBjYXN0IGNvbXBvc2l0ZSBhbGdvcml0aG1zIGFzIGlmIHRoZXkgd2VyZSBuZXcgREggZ3Jv dXBzLCBzbyB0aGVyZSdzIG5vdCBhIGh1Z2UgYW1vdW50IG9mIGxldmVyYWdlIGluIGEgZ2VuZXJp YyBtZWNoYW5pc20uDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgQ2xvdWRmbGFyZS1H b29nbGUgaW1wbGVtZW50YXRpb24gZ2VuZXJhdGVkIHR3byBzZXBhcmF0ZSBzaGFyZWQgc2VjcmV0 cy4gQWxzbyB0aGlzIGRyYWZ0IHJlZmVyZW5jZXMgc2V2ZXJhbCBkaWZmZXJlbnQgImFkIGhvYyIg YXBwcm9hY2hlcyBpbiBpbXBsZW1lbnRhdGlvbnM6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zdGViaWxhLXRscy1oeWJyaWQtZGVzaWduLTAxLg0KDQpXZWxsLCB5ZXMsIGJ1dCBv biB0aGUgd2lyZSBpdCdzIHBhY2thZ2VkIGFzIGEgc2luZ2xlIGdyb3VwIGFuZCBrZXkgc2hhcmUu DQoNCmh0dHBzOi8vYmxvZy5jbG91ZGZsYXJlLmNvbS90aGUtdGxzLXBvc3QtcXVhbnR1bS1leHBl cmltZW50Lw0KDQotRWtyDQoNCg0KQ2Fycmljaw0KDQoNCg0KT24gSmFuIDIsIDIwMjAsIGF0IDEw OjUwIEFNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+ IHdyb3RlOg0KDQoNCg0KT24gVGh1LCBKYW4gMiwgMjAyMCBhdCAxMDo0NSBBTSBDYXJyaWNrIEJh cnRsZSA8Y2JhcnRsZTg5MUBpY2xvdWQuY29tPG1haWx0bzpjYmFydGxlODkxQGljbG91ZC5jb20+ PiB3cm90ZToNCml0J3Mgbm90IHVzZWZ1bCB0byBiZSBwcmVwYXJlZCBpbiB0aGF0IGZhc2hpb24N CnVubGVzcyB0aGUgYWxnb3JpdGhtIHRoYXQgeW91IGFyZSBkZXBsb3lpbmcgaXMgdGhlIG9uZSB0 aGF0IGlzDQpldmVudHVhbGx5IHNlbGVjdGVkLCBiZWNhdXNlIG90aGVyd2lzZSB5b3UganVzdCBo YXZlIHRvIHN0YXJ0IG92ZXINCm9uY2UgdGhlIHNlbGVjdGlvbiBpcyBtYWRlLg0KDQpKdXN0IHRv IGJlIHNwZWNpZmljLCBkbyB5b3UgbWVhbiwgZm9yIGluc3RhbmNlLCBhbGwgdGhlIGNlcnRpZmlj YXRlcyB3aXRoIHRoZSBQUSBhbGdvcml0aG0gdGhhdCB3YXNuJ3QgY2hvc2VuIHdvdWxkIGhhdmUg dG8gYmUgcmV2b2tlZD8NCg0KUHJvYmFibHkgbm90Lg0KDQpBdCBhIGhpZ2ggbGV2ZWwsIHRoZXJl IGFyZSB0d28gcG9zc2libGUgZGVzaWduczoNCg0KMS4gQSBjZXJ0aWZpY2F0ZSB3aGljaCBoYXMg YSBjb21wb3NpdGUgc2lnbmF0dXJlIGluIHBsYWNlIG9mIHRoZSBjbGFzc2ljYWwgc2lnbmF0dXJl IGFuZCB0aHVzIGNhbm5vdCBiZSB2YWxpZGF0ZWQgYnkgb2xkIGNsaWVudHMuDQoyLiBBIGNlcnRp ZmljYXRlIHdoaWNoIGhhcyBhIFBRIHNpZ25hdHVyZSBzb21laG93IGF0dGFjaGVkIGluIGEgd2F5 IHRoYXQgaXQgbGVhdmVzIHRoZSBjbGFzc2ljYWwgc2lnbmF0dXJlIHZhbGlkIChhcyBpbiBhbiBl eHRlbnNpb24pLg0KDQpJbiB0aGUgZm9ybWVyIGNhc2UsIGV2ZXJ5IHNlcnZlciB3b3VsZCBuZWVk IHR3byBjZXJ0aWZpY2F0ZXMgKG9uZSBjb21wb3NpdGUgYW5kIG9uZSBjbGFzc2ljYWwpIGFuZCB1 c2Ugc2lnbmF0dXJlX2FsZ29yaXRobXMgdG8gZGlzdGluZ3Vpc2ggd2hpY2ggb25lIHRvIHVzZS4g T25jZSBjbGllbnRzIHN0b3BwZWQgbGlraW5nIHRoZSBvbGQgUFEgYWxnb3JpdGhtLCB0aGVuIHRo b3NlIGNvbXBvc2l0ZSBjZXJ0aWZpY2F0ZXMgd291bGQgYmVjb21lIGlycmVsZXZhbnQgYW5kIGp1 c3QgYmUgdW51c2VkLiBJbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBjZXJ0aWZpY2F0ZXMgd291bGQg Y29udGludWUgdG8gYmUgdmFsaWQgYW5kIHRoZSBjbGllbnQgY291bGQganVzdCBpZ25vcmUgdGhl IFBRIHBhcnQgb2YgdGhlIHNpZ25hdHVyZS4NCg0KV2hhdCAic3RhcnQgb3ZlciIgbWVhbnMgaW4g dGhpcyBjYXNlIGlzIGdldCB0byB0aGUgcG9pbnQgd2hlcmUgdGhlcmUgaXMgYSBjcml0aWNhbCBt YXNzIG9mIGNsaWVudCBhbmQgc2VydmVyIGRlcGxveW1lbnQsIGEgcHJvY2VzcyB3aGljaCB0YWtl cyB0aW1lLg0KDQp0aGUgcHJpbWFyeSByYXRpb25hbGUgZm9yIGRvaW5nIGNvbXBvc2l0ZSBrZXkg ZXhjaGFuZ2Ugbm93IGlzIHRvDQpkZWZlbmQgYWdhaW5zdCByZXRyb3NwZWN0aXZlIGF0dGFja3Mg aW4gY2FzZSBhIHF1YW50dW0gY29tcHV0ZXIgZXhpc3RzDQppbiB0aGUgZnV0dXJlLiBJbiB0aGlz IHNldHRpbmcsIGl0IGlzbid0IGNyaXRpY2FsbHkgaW1wb3J0YW50IHRvIGhhdmUNCnRoZSBQUSBh bGdvcml0aG0gYmUgdGhlIG9uZSB3ZSBldmVudHVhbGx5IGxhbmQgb24sIGJlY2F1c2UgZWFjaA0K Y29ubmVjdGlvbiBpcyBzZXBhcmF0ZWx5IG5lZ290aWF0ZWQgYW5kIGFzIGxvbmcgYXMgdGhlIFBR IGFsZ29yaXRobQ0KaGFzIHNvbWUgc2VjdXJpdHksIHlvdSdyZSBnZXR0aW5nIGJlbmVnaXQsLg0K DQpJbiB0aGF0IGNhc2UsIHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gdGFrZSB0aGUgbmV4dCBzdGVw IHdpdGggZHJhZnRpbmcgYW4gaW50ZW5kZWQgc3RhbmRhcmQgZm9yIGNvbXBvc2l0ZSBrZXkgZXhj aGFuZ2VzICh0aGF0IGlzIFBRIGFsZ29yaXRobS1hZ25vc3RpYyk/IElmIG5vdCwgd2h5IG5vdD8N Cg0KSSB0aGluayBub3QsIGF0IGxlYXN0IGZvciBUTFMuIFRoZSBjb25zZW5zdXMgb2YgaW1wbGVt ZW50b3JzIHNlZW1zIHRvIGJlIHRoYXQgaXQncyBiZXR0ZXIgdG8ganVzdCBjYXN0IGNvbXBvc2l0 ZSBhbGdvcml0aG1zIGFzIGlmIHRoZXkgd2VyZSBuZXcgREggZ3JvdXBzLCBzbyB0aGVyZSdzIG5v dCBhIGh1Z2UgYW1vdW50IG9mIGxldmVyYWdlIGluIGEgZ2VuZXJpYyBtZWNoYW5pc20uDQoNCi1F a3INCg0KQ2Fycmljaw0KDQoNCg0KDQoNCk9uIERlYyAyNSwgMjAxOSwgYXQgNTo1NyBQTSwgRXJp YyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0K T24gTW9uLCBEZWMgMjMsIDIwMTkgYXQgODozOCBQTSBDYXJyaWNrIEJhcnRsZSA8Y2JhcnRsZTg5 MUBpY2xvdWQuY29tPG1haWx0bzpjYmFydGxlODkxQGljbG91ZC5jb20+PiB3cm90ZToNCj4gSG93 IGNhbiBpdCBiZSB0cnVlIHRoYXQgaXQncyB0b28gZWFybHkgdG8gc3RhcnQgZGV2ZWxvcGluZyBh IHByb3RvY29sDQo+IGZvciBjb21wb3NpdGUga2V5cyBhbmQgc2lnbmF0dXJlcyBmb3IgV2ViIFBL SSB3aGVuIENsb3VkZmxhcmUgYW5kDQo+IEdvb2dsZSBoYXZlIGFscmVhZHkgZmluaXNoZWQgYSBy b3VuZCBvZiBleHBlcmltZW50cyB3aXRoIGNvbXBvc2l0ZSBrZXkNCj4gZXhjaGFuZ2VzPyBNYXli ZSBJJ20gcmVhZGluZyB0b28gbXVjaCBpbnRvIGl0LCBidXQgdGhlIGV4aXN0ZW5jZSBvZg0KPiB0 aG9zZSBleHBlcmltZW50cyBzdWdnZXN0ZWQgdG8gbWUgdGhhdCB0aGUgbmVlZCBmb3IgY29tcG9z aXRlL2NvbXBvc2l0ZQ0KPiBpbXBsZW1lbnRhdGlvbnMgd2FzIGltbWluZW50LiAoSSB1bmRlcnN0 YW5kIHRoYXQgdGhlIGRyYWZ0IGluIHF1ZXN0aW9uDQo+IGNvbmNlcm5zIHNpZ25hdHVyZXMsIG5v dCBrZXkgZXhjaGFuZ2VzLCBidXQgYXBwYXJlbnRseSB0aGVyZSBpc24ndA0KPiBldmVuIGEgZHJh ZnQgZm9yIHRoZSBsYXR0ZXIgeWV0LikNCg0KSVNUTSB0aGF0IHRoZXNlIGNhc2VzIGFyZSBwcmV0 dHkgZGlmZmVyZW50LCBpbiBhIG51bWJlciBvZiByZXNwZWN0cy4NCg0KRmlyc3QsIHRoZSBwcmlt YXJ5IHJhdGlvbmFsZSBmb3IgZG9pbmcgY29tcG9zaXRlIGtleSBleGNoYW5nZSBub3cgaXMgdG8N CmRlZmVuZCBhZ2FpbnN0IHJldHJvc3BlY3RpdmUgYXR0YWNrcyBpbiBjYXNlIGEgcXVhbnR1bSBj b21wdXRlciBleGlzdHMNCmluIHRoZSBmdXR1cmUuIEluIHRoaXMgc2V0dGluZywgaXQgaXNuJ3Qg Y3JpdGljYWxseSBpbXBvcnRhbnQgdG8gaGF2ZQ0KdGhlIFBRIGFsZ29yaXRobSBiZSB0aGUgb25l IHdlIGV2ZW50dWFsbHkgbGFuZCBvbiwgYmVjYXVzZSBlYWNoDQpjb25uZWN0aW9uIGlzIHNlcGFy YXRlbHkgbmVnb3RpYXRlZCBhbmQgYXMgbG9uZyBhcyB0aGUgUFEgYWxnb3JpdGhtDQpoYXMgc29t ZSBzZWN1cml0eSwgeW91J3JlIGdldHRpbmcgYmVuZWdpdCwuDQoNClRoZSBwcmltYXJ5IHJhdGlv bmFsZSBmb3IgZG9pbmcgUFEgYXV0aGVudGljYXRpb24gbm93IChvciBmb3IgdGhhdA0KbWF0dGVy IGNvbXBvc2l0ZSBhdXRoZW50aWNhdGlvbikgaXMgdG8gYmUgcHJlcGFyZWQgZm9yIHRoZSBkYXkg d2hlbiBRQw0KZXhpc3RzIGFuZCB3ZSBhcmUgdGhlcmVmb3JlIHVuYWJsZSB0byByZWx5IG9uIGNs YXNzaWNhbA0KYWxnb3JpdGhtcy4gSG93ZXZlciwgaXQncyBub3QgdXNlZnVsIHRvIGJlIHByZXBh cmVkIGluIHRoYXQgZmFzaGlvbg0KdW5sZXNzIHRoZSBhbGdvcml0aG0gdGhhdCB5b3UgYXJlIGRl cGxveWluZyBpcyB0aGUgb25lIHRoYXQgaXMNCmV2ZW50dWFsbHkgc2VsZWN0ZWQsIGJlY2F1c2Ug b3RoZXJ3aXNlIHlvdSBqdXN0IGhhdmUgdG8gc3RhcnQgb3Zlcg0Kb25jZSB0aGUgc2VsZWN0aW9u IGlzIG1hZGUuDQoNCk1vcmVvdmVyLCBpbiBvcmRlciB0byBiZSB0cnVseSBwcmVwYXJlZCwgd2hh dCB5b3UgbmVlZCBpc24ndA0KcHJpbmNpcGFsbHkgcmVseWluZyBwYXJ0eSBkZXBsb3ltZW50LCBi dXQgcmF0aGVyIGF1dGhlbnRpY2F0aW5nIHBhcnR5DQooaW4gdGhlIGNhc2Ugb2YgdGhlIFdlYlBL SSwgc2VydmVyLXNpZGUpIGRlcGxveW1lbnQuIFRoZSByZWFzb24gZm9yDQp0aGlzIGlzIHRoYXQg aW4gdGhlIHdvcmxkIHdoZXJlIGEgUUMgZXhpc3RzLCB5b3UgZG9uJ3QgaGF2ZSBwcm90ZWN0aW9u DQp1bnRpbCB0aGUgcmVseWluZyBwYXJ0eSByZWZ1c2VzIHRvIGFjY2VwdCB0aGUgY2xhc3NpY2Fs IGNyZWRlbnRpYWwNClswXSwgYW5kIGF0IHByZXNlbnQsIGFueSBjbGllbnQgd2hpY2ggZG9lcyBz byB3aWxsIGVmZmVjdGl2ZWx5IGJlDQp1bmFibGUgdG8gY29tbXVuaWNhdGUuIEFuZCBpbiBvcmRl ciB0byBtYWtlIHRoYXQgaGFwcGVuLCByZWx5aW5nDQpwYXJ0aWVzIHdpbGwgaGF2ZSB0byByZXF1 aXJlIGEgcG9zdC1xdWFudHVtIGFsZ29yaXRobSAobW9zdCBsaWtlbHkgYXMNCmEgY29tcG9zaXRl KSBhbmQgdGhhdCdzIHNvbWV0aGluZyBJIGRvbid0IGV4cGVjdCB0aGVtIHRvIGJlIHdpbGxpbmcg dG8gZG8NCnVudGlsIHRoZXJlJ3Mgd2lkZXNwcmVhZCBhZ3JlZW1lbnQgb24gd2hhdCB0aGF0IGFs Z29yaXRobSBzaG91bGQgYmUuDQoNCg0KPiBJZiBub3Qgbm93LCB3aGVuPyBBZnRlciBOSVNUIGNy b3ducyBhIHdpbm5lcj8gSSBkb24ndCBzZWUgd2h5IGl0J3MNCj4gbmVjZXNzYXJ5IHRvIHdhaXQg dGhhdCBsb25nIGdpdmVuIHRoYXQgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucyBhcmUNCj4gYWxnb3Jp dGhtLWluZGVwZW5kZW50LiBBbmQgc2luY2UgdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIHRh a2VzIGENCj4gd2hpbGUsIHdvbid0IHdhaXRpbmcgdW50aWwgdGhlbiBtZWFuIHRoYXQgdGhlcmUg d29uJ3QgYmUgYSBzdGFuZGFyZA0KPiB1bnRpbCBhZnRlciBpdCdzIG5lZWRlZD8NCg0KTm8sIGkg ZG9uJ3QgdGhpbmsgc28uDQoNCkZvciB0aGUgcmVhc29ucyBhYm92ZSwgSVNUTSB0aGF0IHJlYWwg ZGVwbG95bWVudCB3aWxsIGhhdmUgdG8gd2FpdA0KdW50aWwgd2UgaGF2ZSBhIHNlbGVjdGVkIGFs Z29yaXRobS4gT25lIGNvdWxkLCBhcyB5b3Ugc3VnZ2VzdCwgZGVwbG95DQpzb21lIHNvcnQgb2Yg bXVsdGktYWxnb3JpdGhtIGNvbnRhaW5lciwgYnV0IElNTyB3ZSB3aWxsIGJlIGZhciBiZXR0ZXIN Cm9mZiBqdXN0IGRlcGxveWluZyBuZXcgY29tcG9zaXRlIGFsZ29yaXRobXMgYXMgaWYgdGhlIHdl cmUgc2luZ2xlDQpuZXcgYWxnb3JpdGhtcywgaW4gdGhlIHNhbWUgd2F5IGFzIHdlIGhhdmUgZG9u ZSBmb3Iga2V5IGVzdGFibGlzaG1lbnQuDQoNCkZvciB0aGlzIHJlYXNvbiwgSSB0aGluayB3ZSBv dWdodCB0byB3YWl0IHVudGlsIHRoZXJlIGlzIGEgY29uc2Vuc3VzDQpQUSBzaWduYXR1cmUgYWxn b3JpdGhtLCBhdCBsZWFzdCBmb3IgdGhlIFdlYlBLSS4NCg0KLUVrcg0KDQpbMF0gVGhpcyBpcyB3 aHkgdGhpcyBraW5kIG9mIGNvbXBvc2l0ZSBpc24ndCBoZWxwZnVsIGluIHRoZSB3b3JsZA0Kd2hl cmUgYSBzZWNyZXQgUUMgZXhpc3RzIG5vdC4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpTZWNkaXNw YXRjaEBpZXRmLm9yZzxtYWlsdG86U2VjZGlzcGF0Y2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQoNCg== --_000_DM6PR11MB38835E0C6C931C9E9BE676689B3E0DM6PR11MB3883namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiM3MDMw QTA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTM2MTAxMjQ0MzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjE0NzEwMTM2NiAxMDM3NzA3NjE0 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MzA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+D mDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPkVrciBzYWlkOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzAzMEEwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbiB0aGUgZm9ybWVyIGNhc2UsIGV2ZXJ5IHNlcnZlciB3b3Vs ZCBuZWVkIHR3byBjZXJ0aWZpY2F0ZXMgKG9uZSBjb21wb3NpdGUgYW5kIG9uZSBjbGFzc2ljYWwp IGFuZCB1c2Ugc2lnbmF0dXJlX2FsZ29yaXRobXMgdG8gZGlzdGluZ3Vpc2ggd2hpY2ggb25lIHRv IHVzZS48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojNzAzMEEwIj5JIGFncmVlIHdpdGggeW91ciBjb25jbHVzaW9uIGFib3V0IGNvbXBvc2l0 ZSBicmVha2luZyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3MDMwQTAiPlRoYXQgc2FpZCwgSSBjYXV0aW9uIHVzIGFnYWluc3QgdGhpbmtpbmcg YWJvdXQgdGhpcyBwcm9ibGVtIG9ubHkgaW4gdGVybXMgb2YgYSBzaW5nbGUgdXNlLWNhc2Ugb3Ig cHJvdG9jb2wgKFRMUyBpbiB0aGlzIGNhc2UpLiZuYnNwOyBJIHdhbnQgdG8ga2VlcCB0aGlzIGRp c2N1c3Npb24gY29uc2lkZXJpbmcgY2VydGlmaWNhdGUgdXNlLWNhc2VzIHRoYXQgZG9u4oCZdCBo YXZlDQogYWxnb3JpdGhtIG5lZ290aWF0aW9uIG1lY2hhbmlzbXMsIGZvciBleGFtcGxlIGNvZGUt c2lnbmluZywgUy9NSU1FLCBQS0kgc21hcnQgY2FyZHMsIGZpbGUgZW5jcnlwdGlvbiwgd2hhdGV2 ZXIgdXNlcyBjZXJ0aWZpY2F0ZXMgaW4gYSB3YXkgdGhhdCBpc27igJl0IOKAnG9ubGluZeKAnS4m bmJzcDsgSSB3b3VsZCBsb3ZlIHRvIHNlZSB0aGUgSUVURiBwcm92aWRlIGEgc29sdXRpb24gdGhh dCBhcHBsaWVzIHRvIGNlcnRpZmljYXRlcyBhbmQgc2lnbmF0dXJlcyBpbiBnZW5lcmFsLA0KIHJh dGhlciB0aGFuIHB1bnRpbmcgdGhpcyBwcm9ibGVtIHRvIGVhY2ggcHJvdG9jb2wgZGVzaWduIHRl YW0gdG8gc29sdmUgaW5kZXBlbmRlbnRseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgZG9p bmcgUFEgYXV0aGVudGljYXRpb24gbm93IChvciBmb3IgdGhhdDxicj4NCm1hdHRlciBjb21wb3Np dGUgYXV0aGVudGljYXRpb24pIGlzIHRvIGJlIHByZXBhcmVkIGZvciB0aGUgZGF5IHdoZW4gUUM8 YnI+DQpleGlzdHMgYW5kIHdlIGFyZSB0aGVyZWZvcmUgdW5hYmxlIHRvIHJlbHkgb24gY2xhc3Np Y2FsPGJyPg0KYWxnb3JpdGhtcy4gSG93ZXZlciwgaXQncyBub3QgdXNlZnVsIHRvIGJlIHByZXBh cmVkIGluIHRoYXQgZmFzaGlvbjxicj4NCnVubGVzcyB0aGUgYWxnb3JpdGhtIHRoYXQgeW91IGFy ZSBkZXBsb3lpbmcgaXMgdGhlIG9uZSB0aGF0IGlzPGJyPg0KZXZlbnR1YWxseSBzZWxlY3RlZCwg YmVjYXVzZSBvdGhlcndpc2UgeW91IGp1c3QgaGF2ZSB0byBzdGFydCBvdmVyPGJyPg0Kb25jZSB0 aGUgc2VsZWN0aW9uIGlzIG1hZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojNzAzMEEwIj5UaGlzIGNvbmNsdXNpb24g4oCTIHRoYXQgeW914oCZcmUgb25seSBn ZXR0aW5nIHNlY3VyaXR5IHZhbHVlIG9uY2UgYSBQUSBleGlzdHMsIGFuZCBhbnkgYWxnIGltcGxl bWVudGF0aW9uIHdlIGNob3NlIHRvZGF5IHdpbGwgbGlrZWx5IGJlIG9ic29sZXRlIGJ5IHRoZW4g LS0gaXMgcHJvYmFibHkgcmlnaHQgZm9yIGJyb3dzZXJzLCBidXQgd2hhdCBhYm91dCBJb1QgZGV2 aWNlcw0KIHZhbGlkYXRpbmcgdGhlaXIgZmlybXdhcmUgc2lnbmF0dXJlIG9uIGJvb3Q/IE9yIFBL SSBzbWFydGNhcmRzPyZuYnNwOyBPciBsZWdhbCBjb250cmFjdHMgc2lnbmVkIHVuZGVyIGVJREFT PyAmbmJzcDtUb2RheSB3ZSBhcmUgY3JlYXRpbmcgY2VydGlmaWNhdGVzIGFuZCBzaWduZWQgZGF0 YSBvYmplY3RzIHRoYXQgd2lsbCBvdXRsaXZlIHRoZSBhZHZlbnQgb2YgYSBRQy4gJm5ic3A7SSB0 aGluayB0aGF0IGJsdXJzIGNsb3NlciB0byB0aGUg4oCccmV0cm9zcGVjdGl2ZSBhdHRhY2vigJ0N CiBzY2VuYXJpbyB0aGF0IHlvdSB1c2VkIGZvciBtb3RpdmF0aW5nIGNvbXBvc2l0ZSBrZXkgZXhj aGFuZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzAzMEEwIj5XaGlsZSBJ4oCZbSBh d2FyZSB0aGF0IEnigJltIHVzaW5nIG1vdGl2YXRpbmcgZXhhbXBsZXMgZnJvbSBvdXRzaWRlIHRo ZSBJRVRGLCBJIHRoaW5rIHdlIGhhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gZGVmaW5lIGEgc3RhbmRh cmQgdGhhdCBpcyBnZW5lcmljIGZvciBhbGwgKG9yIGF0IGxlYXN0IG1vc3QpIGNlcnRpZmljYXRl IHVzZS1jYXNlcy4gJm5ic3A7TGV04oCZcyBkbyB0aGUgZGViYXRlDQogaGVyZSBhYm91dCBjYXJy eWluZyBtdWx0aXBsZSBzaWduYXR1cmVzIGFuZCB0aGUgc2VtYW50aWNzIG9mIHZhbGlkYXRpbmcg aXQsIHJhdGhlciB0aGFuIHB1c2hpbmcgaXQgb3V0IHRvIGVhY2ggcHJvdG9jb2wgZGVzaWduIHRl YW0gdG8gZGViYXRlIGluZGVwZW5kZW50bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj NzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOiM3MDMwQTAiPi0tLTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzAzMEEwIj5NaWtlPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwMzBBMCI+IE91 bnN3b3J0aA0KPGI+fDwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzAzMEEwIj5PZmZpY2U8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmdyYXkiPjogJiM0MzsxICg2MTMpIDI3MC0yODczPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojNzAzMEEwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFNlY2Rpc3BhdGNoICZsdDtzZWNk aXNwYXRjaC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5FcmljIFJl c2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IEphbnVhcnkgMiwgMjAyMCAyOjExIFBNPGJyPg0KPGI+ VG86PC9iPiBDYXJyaWNrIEJhcnRsZSAmbHQ7Y2JhcnRsZTg5MUBpY2xvdWQuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gRHIuIFBhbGEgJmx0O21hZHdvbGZAb3BlbmNhLm9yZyZndDs7IFNhbHosIFJp Y2ggJmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7OyBJRVRGIFNlY0Rpc3BhdGNoICZsdDtzZWNkaXNw YXRjaEBpZXRmLm9yZyZndDs7IFN0ZXBoZW4gRmFycmVsbCAmbHQ7c3RlcGhlbi5mYXJyZWxsQGNz LnRjZC5pZSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXVJlOiBbU2VjZGlzcGF0 Y2hdIENsYXJpZmljYXRpb24gUXVlc3Rpb24gZm9yIHRoZSBDb21tZW50IGZyb20gRXJpYyBSZXNj b3JsYSAoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPldBUk5JTkc6 PC9zcGFuPjwvc3Ryb25nPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgb3V0c2lkZSBvZiBFbnRydXN0 IERhdGFjYXJkLjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPkRPIE5PVCBDTElDSzwvc3Bhbj48L3N0 cm9uZz4gbGlua3Mgb3IgYXR0YWNobWVudHMgdW5sZXNzIHlvdSB0cnVzdCB0aGUgc2VuZGVyIGFu ZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuPG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIg c2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMiwgMjAyMCBhdCAxMToxOSBBTSBDYXJy aWNrIEJhcnRsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNiYXJ0bGU4OTFAaWNsb3VkLmNvbSI+Y2Jh cnRsZTg5MUBpY2xvdWQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaGF0ICZxdW90O3N0YXJ0IG92ZXImcXVvdDsgbWVhbnMgaW4gdGhpcyBjYXNlIGlz IGdldCB0byB0aGUgcG9pbnQgd2hlcmUgdGhlcmUgaXMgYSBjcml0aWNhbCBtYXNzIG9mIGNsaWVu dCBhbmQgc2VydmVyIGRlcGxveW1lbnQsIGEgcHJvY2VzcyB3aGljaCB0YWtlcyB0aW1lLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIG5vdCwg YXQgbGVhc3QgZm9yIFRMUy4gVGhlIGNvbnNlbnN1cyBvZiBpbXBsZW1lbnRvcnMgc2VlbXMgdG8g YmUgdGhhdCBpdCdzIGJldHRlciB0byBqdXN0IGNhc3QgY29tcG9zaXRlIGFsZ29yaXRobXMgYXMg aWYgdGhleSB3ZXJlIG5ldyBESCBncm91cHMsIHNvIHRoZXJlJ3Mgbm90IGEgaHVnZSBhbW91bnQg b2YgbGV2ZXJhZ2UgaW4gYSBnZW5lcmljIG1lY2hhbmlzbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgQ2xvdWRmbGFyZS1Hb29nbGUgaW1w bGVtZW50YXRpb24gZ2VuZXJhdGVkIHR3byBzZXBhcmF0ZSBzaGFyZWQgc2VjcmV0cy4gQWxzbyB0 aGlzIGRyYWZ0IHJlZmVyZW5jZXMgc2V2ZXJhbCBkaWZmZXJlbnQgJnF1b3Q7YWQgaG9jJnF1b3Q7 IGFwcHJvYWNoZXMgaW4gaW1wbGVtZW50YXRpb25zOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdGViaWxhLXRscy1oeWJyaWQtZGVzaWduLTAxIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXN0ZWJpbGEtdGxz LWh5YnJpZC1kZXNpZ24tMDE8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlbGwsIHllcywgYnV0 IG9uIHRoZSB3aXJlIGl0J3MgcGFja2FnZWQgYXMgYSBzaW5nbGUgZ3JvdXAgYW5kIGtleSBzaGFy ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgaHJlZj0iaHR0cHM6Ly9ibG9nLmNsb3VkZmxhcmUuY29tL3RoZS10bHMtcG9zdC1xdWFudHVt LWV4cGVyaW1lbnQvIj5odHRwczovL2Jsb2cuY2xvdWRmbGFyZS5jb20vdGhlLXRscy1wb3N0LXF1 YW50dW0tZXhwZXJpbWVudC88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhcnJpY2s8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDIsIDIwMjAs IGF0IDEwOjUwIEFNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0u Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ T24gVGh1LCBKYW4gMiwgMjAyMCBhdCAxMDo0NSBBTSBDYXJyaWNrIEJhcnRsZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNiYXJ0bGU4OTFAaWNsb3VkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNiYXJ0bGU4 OTFAaWNsb3VkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5pdCdzIG5vdCB1c2VmdWwgdG8gYmUgcHJlcGFy ZWQgaW4gdGhhdCBmYXNoaW9uPGJyPg0KdW5sZXNzIHRoZSBhbGdvcml0aG0gdGhhdCB5b3UgYXJl IGRlcGxveWluZyBpcyB0aGUgb25lIHRoYXQgaXM8YnI+DQpldmVudHVhbGx5IHNlbGVjdGVkLCBi ZWNhdXNlIG90aGVyd2lzZSB5b3UganVzdCBoYXZlIHRvIHN0YXJ0IG92ZXI8YnI+DQpvbmNlIHRo ZSBzZWxlY3Rpb24gaXMgbWFkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkp1c3QgdG8gYmUgc3BlY2lmaWMs IGRvIHlvdSBtZWFuLCBmb3IgaW5zdGFuY2UsIGFsbCB0aGUgY2VydGlmaWNhdGVzIHdpdGggdGhl IFBRIGFsZ29yaXRobSB0aGF0IHdhc24ndCBjaG9zZW4gd291bGQgaGF2ZSB0byBiZSByZXZva2Vk PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+UHJvYmFibHkgbm90LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+QXQgYSBoaWdoIGxldmVsLCB0aGVyZSBhcmUgdHdvIHBvc3Np YmxlIGRlc2lnbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4xLiBBIGNlcnRpZmljYXRlIHdoaWNoIGhhcyBhIGNvbXBvc2l0ZSBzaWduYXR1cmUgaW4g cGxhY2Ugb2YgdGhlIGNsYXNzaWNhbCBzaWduYXR1cmUgYW5kIHRodXMgY2Fubm90IGJlIHZhbGlk YXRlZCBieSBvbGQgY2xpZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mi4gQSBjZXJ0aWZpY2F0 ZSB3aGljaCBoYXMgYSBQUSBzaWduYXR1cmUgc29tZWhvdyBhdHRhY2hlZCBpbiBhIHdheSB0aGF0 IGl0IGxlYXZlcyB0aGUgY2xhc3NpY2FsIHNpZ25hdHVyZSB2YWxpZCAoYXMgaW4gYW4gZXh0ZW5z aW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklu IHRoZSBmb3JtZXIgY2FzZSwgZXZlcnkgc2VydmVyIHdvdWxkIG5lZWQgdHdvIGNlcnRpZmljYXRl cyAob25lIGNvbXBvc2l0ZSBhbmQgb25lIGNsYXNzaWNhbCkgYW5kIHVzZSBzaWduYXR1cmVfYWxn b3JpdGhtcyB0byBkaXN0aW5ndWlzaCB3aGljaCBvbmUgdG8gdXNlLiBPbmNlIGNsaWVudHMNCiBz dG9wcGVkIGxpa2luZyB0aGUgb2xkIFBRIGFsZ29yaXRobSwgdGhlbiB0aG9zZSBjb21wb3NpdGUg Y2VydGlmaWNhdGVzIHdvdWxkIGJlY29tZSBpcnJlbGV2YW50IGFuZCBqdXN0IGJlIHVudXNlZC4g SW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgY2VydGlmaWNhdGVzIHdvdWxkIGNvbnRpbnVlIHRvIGJl IHZhbGlkIGFuZCB0aGUgY2xpZW50IGNvdWxkIGp1c3QgaWdub3JlIHRoZSBQUSBwYXJ0IG9mIHRo ZSBzaWduYXR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5XaGF0ICZxdW90O3N0YXJ0IG92ZXImcXVvdDsgbWVhbnMgaW4gdGhpcyBjYXNlIGlzIGdl dCB0byB0aGUgcG9pbnQgd2hlcmUgdGhlcmUgaXMgYSBjcml0aWNhbCBtYXNzIG9mIGNsaWVudCBh bmQgc2VydmVyIGRlcGxveW1lbnQsIGEgcHJvY2VzcyB3aGljaCB0YWtlcyB0aW1lLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgZG9p bmcgY29tcG9zaXRlIGtleSBleGNoYW5nZSBub3cgaXMgdG88YnI+DQpkZWZlbmQgYWdhaW5zdCBy ZXRyb3NwZWN0aXZlIGF0dGFja3MgaW4gY2FzZSBhIHF1YW50dW0gY29tcHV0ZXIgZXhpc3RzPGJy Pg0KaW4gdGhlIGZ1dHVyZS4gSW4gdGhpcyBzZXR0aW5nLCBpdCBpc24ndCBjcml0aWNhbGx5IGlt cG9ydGFudCB0byBoYXZlPGJyPg0KdGhlIFBRIGFsZ29yaXRobSBiZSB0aGUgb25lIHdlIGV2ZW50 dWFsbHkgbGFuZCBvbiwgYmVjYXVzZSBlYWNoPGJyPg0KY29ubmVjdGlvbiBpcyBzZXBhcmF0ZWx5 IG5lZ290aWF0ZWQgYW5kIGFzIGxvbmcgYXMgdGhlIFBRIGFsZ29yaXRobTxicj4NCmhhcyBzb21l IHNlY3VyaXR5LCB5b3UncmUgZ2V0dGluZyBiZW5lZ2l0LC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkluIHRoYXQgY2FzZSwgd291bGQgaXQgbWFrZSBzZW5zZSB0byB0YWtlIHRoZSBu ZXh0IHN0ZXAgd2l0aCBkcmFmdGluZyBhbiBpbnRlbmRlZCBzdGFuZGFyZCBmb3IgY29tcG9zaXRl IGtleSBleGNoYW5nZXMgKHRoYXQgaXMgUFEgYWxnb3JpdGhtLWFnbm9zdGljKT8gSWYgbm90LCB3 aHkgbm90PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIG5vdCwgYXQgbGVhc3QgZm9yIFRMUy4gVGhl IGNvbnNlbnN1cyBvZiBpbXBsZW1lbnRvcnMgc2VlbXMgdG8gYmUgdGhhdCBpdCdzIGJldHRlciB0 byBqdXN0IGNhc3QgY29tcG9zaXRlIGFsZ29yaXRobXMgYXMgaWYgdGhleSB3ZXJlIG5ldyBESCBn cm91cHMsIHNvIHRoZXJlJ3Mgbm90DQogYSBodWdlIGFtb3VudCBvZiBsZXZlcmFnZSBpbiBhIGdl bmVyaWMgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+LUVrcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DYXJyaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gRGVjIDI1LCAy MDE5LCBhdCA1OjU3IFBNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0 Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBNb24s IERlYyAyMywgMjAxOSBhdCA4OjM4IFBNIENhcnJpY2sgQmFydGxlICZsdDs8YSBocmVmPSJtYWls dG86Y2JhcnRsZTg5MUBpY2xvdWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2JhcnRsZTg5MUBpY2xv dWQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgSG93IGNhbiBp dCBiZSB0cnVlIHRoYXQgaXQncyB0b28gZWFybHkgdG8gc3RhcnQgZGV2ZWxvcGluZyBhIHByb3Rv Y29sPGJyPg0KJmd0OyBmb3IgY29tcG9zaXRlIGtleXMgYW5kIHNpZ25hdHVyZXMgZm9yIFdlYiBQ S0kgd2hlbiBDbG91ZGZsYXJlIGFuZDxicj4NCiZndDsgR29vZ2xlIGhhdmUgYWxyZWFkeSBmaW5p c2hlZCBhIHJvdW5kIG9mIGV4cGVyaW1lbnRzIHdpdGggY29tcG9zaXRlIGtleTxicj4NCiZndDsg ZXhjaGFuZ2VzPyBNYXliZSBJJ20gcmVhZGluZyB0b28gbXVjaCBpbnRvIGl0LCBidXQgdGhlIGV4 aXN0ZW5jZSBvZjxicj4NCiZndDsgdGhvc2UgZXhwZXJpbWVudHMgc3VnZ2VzdGVkIHRvIG1lIHRo YXQgdGhlIG5lZWQgZm9yIGNvbXBvc2l0ZS9jb21wb3NpdGU8YnI+DQomZ3Q7IGltcGxlbWVudGF0 aW9ucyB3YXMgaW1taW5lbnQuIChJIHVuZGVyc3RhbmQgdGhhdCB0aGUgZHJhZnQgaW4gcXVlc3Rp b248YnI+DQomZ3Q7IGNvbmNlcm5zIHNpZ25hdHVyZXMsIG5vdCBrZXkgZXhjaGFuZ2VzLCBidXQg YXBwYXJlbnRseSB0aGVyZSBpc24ndDxicj4NCiZndDsgZXZlbiBhIGRyYWZ0IGZvciB0aGUgbGF0 dGVyIHlldC4pPGJyPg0KPGJyPg0KSVNUTSB0aGF0IHRoZXNlIGNhc2VzIGFyZSBwcmV0dHkgZGlm ZmVyZW50LCBpbiBhIG51bWJlciBvZiByZXNwZWN0cy48YnI+DQo8YnI+DQpGaXJzdCwgdGhlIHBy aW1hcnkgcmF0aW9uYWxlIGZvciBkb2luZyBjb21wb3NpdGUga2V5IGV4Y2hhbmdlIG5vdyBpcyB0 bzxicj4NCmRlZmVuZCBhZ2FpbnN0IHJldHJvc3BlY3RpdmUgYXR0YWNrcyBpbiBjYXNlIGEgcXVh bnR1bSBjb21wdXRlciBleGlzdHM8YnI+DQppbiB0aGUgZnV0dXJlLiBJbiB0aGlzIHNldHRpbmcs IGl0IGlzbid0IGNyaXRpY2FsbHkgaW1wb3J0YW50IHRvIGhhdmU8YnI+DQp0aGUgUFEgYWxnb3Jp dGhtIGJlIHRoZSBvbmUgd2UgZXZlbnR1YWxseSBsYW5kIG9uLCBiZWNhdXNlIGVhY2g8YnI+DQpj b25uZWN0aW9uIGlzIHNlcGFyYXRlbHkgbmVnb3RpYXRlZCBhbmQgYXMgbG9uZyBhcyB0aGUgUFEg YWxnb3JpdGhtPGJyPg0KaGFzIHNvbWUgc2VjdXJpdHksIHlvdSdyZSBnZXR0aW5nIGJlbmVnaXQs Ljxicj4NCjxicj4NClRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgZG9pbmcgUFEgYXV0aGVudGlj YXRpb24gbm93IChvciBmb3IgdGhhdDxicj4NCm1hdHRlciBjb21wb3NpdGUgYXV0aGVudGljYXRp b24pIGlzIHRvIGJlIHByZXBhcmVkIGZvciB0aGUgZGF5IHdoZW4gUUM8YnI+DQpleGlzdHMgYW5k IHdlIGFyZSB0aGVyZWZvcmUgdW5hYmxlIHRvIHJlbHkgb24gY2xhc3NpY2FsPGJyPg0KYWxnb3Jp dGhtcy4gSG93ZXZlciwgaXQncyBub3QgdXNlZnVsIHRvIGJlIHByZXBhcmVkIGluIHRoYXQgZmFz aGlvbjxicj4NCnVubGVzcyB0aGUgYWxnb3JpdGhtIHRoYXQgeW91IGFyZSBkZXBsb3lpbmcgaXMg dGhlIG9uZSB0aGF0IGlzPGJyPg0KZXZlbnR1YWxseSBzZWxlY3RlZCwgYmVjYXVzZSBvdGhlcndp c2UgeW91IGp1c3QgaGF2ZSB0byBzdGFydCBvdmVyPGJyPg0Kb25jZSB0aGUgc2VsZWN0aW9uIGlz IG1hZGUuPGJyPg0KPGJyPg0KTW9yZW92ZXIsIGluIG9yZGVyIHRvIGJlIHRydWx5IHByZXBhcmVk LCB3aGF0IHlvdSBuZWVkIGlzbid0PGJyPg0KcHJpbmNpcGFsbHkgcmVseWluZyBwYXJ0eSBkZXBs b3ltZW50LCBidXQgcmF0aGVyIGF1dGhlbnRpY2F0aW5nIHBhcnR5PGJyPg0KKGluIHRoZSBjYXNl IG9mIHRoZSBXZWJQS0ksIHNlcnZlci1zaWRlKSBkZXBsb3ltZW50LiBUaGUgcmVhc29uIGZvcjxi cj4NCnRoaXMgaXMgdGhhdCBpbiB0aGUgd29ybGQgd2hlcmUgYSBRQyBleGlzdHMsIHlvdSBkb24n dCBoYXZlIHByb3RlY3Rpb248YnI+DQp1bnRpbCB0aGUgcmVseWluZyBwYXJ0eSByZWZ1c2VzIHRv IGFjY2VwdCB0aGUgY2xhc3NpY2FsIGNyZWRlbnRpYWw8YnI+DQpbMF0sIGFuZCBhdCBwcmVzZW50 LCBhbnkgY2xpZW50IHdoaWNoIGRvZXMgc28gd2lsbCBlZmZlY3RpdmVseSBiZTxicj4NCnVuYWJs ZSB0byBjb21tdW5pY2F0ZS4gQW5kIGluIG9yZGVyIHRvIG1ha2UgdGhhdCBoYXBwZW4sIHJlbHlp bmc8YnI+DQpwYXJ0aWVzIHdpbGwgaGF2ZSB0byByZXF1aXJlIGEgcG9zdC1xdWFudHVtIGFsZ29y aXRobSAobW9zdCBsaWtlbHkgYXM8YnI+DQphIGNvbXBvc2l0ZSkgYW5kIHRoYXQncyBzb21ldGhp bmcgSSBkb24ndCBleHBlY3QgdGhlbSB0byBiZSB3aWxsaW5nIHRvIGRvPGJyPg0KdW50aWwgdGhl cmUncyB3aWRlc3ByZWFkIGFncmVlbWVudCBvbiB3aGF0IHRoYXQgYWxnb3JpdGhtIHNob3VsZCBi ZS48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IElmIG5vdCBub3csIHdoZW4/IEFmdGVyIE5JU1QgY3Jv d25zIGEgd2lubmVyPyBJIGRvbid0IHNlZSB3aHkgaXQnczxicj4NCiZndDsgbmVjZXNzYXJ5IHRv IHdhaXQgdGhhdCBsb25nIGdpdmVuIHRoYXQgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucyBhcmU8YnI+ DQomZ3Q7IGFsZ29yaXRobS1pbmRlcGVuZGVudC4gQW5kIHNpbmNlIHRoZSBzdGFuZGFyZGl6YXRp b24gcHJvY2VzcyB0YWtlcyBhPGJyPg0KJmd0OyB3aGlsZSwgd29uJ3Qgd2FpdGluZyB1bnRpbCB0 aGVuIG1lYW4gdGhhdCB0aGVyZSB3b24ndCBiZSBhIHN0YW5kYXJkPGJyPg0KJmd0OyB1bnRpbCBh ZnRlciBpdCdzIG5lZWRlZD88YnI+DQo8YnI+DQpObywgaSBkb24ndCB0aGluayBzby48YnI+DQo8 YnI+DQpGb3IgdGhlIHJlYXNvbnMgYWJvdmUsIElTVE0gdGhhdCByZWFsIGRlcGxveW1lbnQgd2ls bCBoYXZlIHRvIHdhaXQ8YnI+DQp1bnRpbCB3ZSBoYXZlIGEgc2VsZWN0ZWQgYWxnb3JpdGhtLiBP bmUgY291bGQsIGFzIHlvdSBzdWdnZXN0LCBkZXBsb3k8YnI+DQpzb21lIHNvcnQgb2YgbXVsdGkt YWxnb3JpdGhtIGNvbnRhaW5lciwgYnV0IElNTyB3ZSB3aWxsIGJlIGZhciBiZXR0ZXI8YnI+DQpv ZmYganVzdCBkZXBsb3lpbmcgbmV3IGNvbXBvc2l0ZSBhbGdvcml0aG1zIGFzIGlmIHRoZSB3ZXJl IHNpbmdsZTxicj4NCm5ldyBhbGdvcml0aG1zLCBpbiB0aGUgc2FtZSB3YXkgYXMgd2UgaGF2ZSBk b25lIGZvciBrZXkgZXN0YWJsaXNobWVudC48YnI+DQo8YnI+DQpGb3IgdGhpcyByZWFzb24sIEkg dGhpbmsgd2Ugb3VnaHQgdG8gd2FpdCB1bnRpbCB0aGVyZSBpcyBhIGNvbnNlbnN1czxicj4NClBR IHNpZ25hdHVyZSBhbGdvcml0aG0sIGF0IGxlYXN0IGZvciB0aGUgV2ViUEtJLjxicj4NCjxicj4N Ci1Fa3I8YnI+DQo8YnI+DQpbMF0gVGhpcyBpcyB3aHkgdGhpcyBraW5kIG9mIGNvbXBvc2l0ZSBp c24ndCBoZWxwZnVsIGluIHRoZSB3b3JsZDxicj4NCndoZXJlIGEgc2VjcmV0IFFDIGV4aXN0cyBu b3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K U2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNlY2Rpc3BhdGNo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U2VjZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRj aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2VjZGlzcGF0Y2g8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR11MB38835E0C6C931C9E9BE676689B3E0DM6PR11MB3883namp_-- From nobody Wed Jan 8 08:44:29 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3C1201EA for ; Wed, 8 Jan 2020 08:44:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QvKGtnxZgDU for ; Wed, 8 Jan 2020 08:44:24 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EE8120898 for ; Wed, 8 Jan 2020 08:44:23 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id m26so3964338ljc.13 for ; Wed, 08 Jan 2020 08:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZ/odt34TDKKnWPFssCO6pd+sSzCNg+p/UNe6xECIwo=; b=ao8g3MoVvYMOtrcUzP5dUDH/wVOLRg1nWQEwTomreeXGEVPKuKBUzEjY+uo2001IJ9 FuYPG6Ml152538ehrRWjeH9vOHoU4uGtyrYHHxoBj92vgnLUNF8YTaQzMtSuRh5MhMMg Ds/JGUikHv0T0Z6i0pKntTnYfFjomCrH1xyWRnZv+ViYvML1vLYTIWrkEe/OJUgiOQuq znKcukgVzHk+IKAKZGpU9LYfF13m49tsb5bDPKYFc83Tx+gLSKxgX7AoIVHxbm6r+yiW YvoupFkzNOHgrklTo1jFjbwPSO5tRapWsxTNFd18lvinEbn7nmwxPK6zALwppk8bOMRL c+/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GZ/odt34TDKKnWPFssCO6pd+sSzCNg+p/UNe6xECIwo=; b=geLI8x5JWuDTsjoWVD7mMnPMK+p+3kbK0yhVO25ReV6297seV9EiA5P/lYyOCVJhk2 WXGMPA/Us+bqif6Tth1Q2cGV46XbvGXKdQJXD9Bjhl+9jwDb8INsoflxNePGDvq32Err a9qZ3rz2XepesuLjWJXIx4rp1N/OzZFCE740po7s88L7mWoLl6Edi9R0SuxAd8iQnmH+ 2X9/TjMQ1nHpNACdKK7n1oon0zVB+u1KPGyt335/bc0yqCVq7WJGNregtyu7s96+OZPR GFe8mKC62jMqRokVLZzrXZgEAkKuc9yx9xnCcTbjG8dTfJJIDsYhUSEf10U33R/RYIjk geFA== X-Gm-Message-State: APjAAAVDhB4RNDoZho3lpSr3ltzaF2tqQWnDwWtfHRD+TbmFjv2I/Imc 5ZfRoKmya7QLy5Ocn0QQhUc1xIP7+mpIC4IueygU+g== X-Google-Smtp-Source: APXvYqx5C5ylVOvoSSniJGSXk36QmJLdaj/YBoaZe96HxvuuYpEIrDtoBjzR5aYoqZca+sKgOdWAq6T/n5PPzPJyuTQ= X-Received: by 2002:a2e:95c4:: with SMTP id y4mr3523822ljh.38.1578501861590; Wed, 08 Jan 2020 08:44:21 -0800 (PST) MIME-Version: 1.0 References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> In-Reply-To: From: Eric Rescorla Date: Wed, 8 Jan 2020 08:43:45 -0800 Message-ID: To: Mike Ounsworth Cc: Carrick Bartle , "Dr. Pala" , "Salz, Rich" , IETF SecDispatch , Stephen Farrell Content-Type: multipart/alternative; boundary="000000000000bce8c6059ba39a99" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla ( X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 16:44:27 -0000 --000000000000bce8c6059ba39a99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mike, The context of this thread is my comments at the mic that I didn't think this made much sense for the WebPKI. I haven't fully thought through the non-WebPKI cases. With that said, if you are concerned about long-term signatures, I don't really understand the point of a hybrid scheme, given that we don;'t really have that high confidence in any PQ signature system other than hash signatures, so why not *just* use hash signatures? -Ekr On Wed, Jan 8, 2020 at 8:26 AM Mike Ounsworth < Mike.Ounsworth@entrustdatacard.com> wrote: > Ekr said: > > > > In the former case, every server would need two certificates (one > composite and one classical) and use signature_algorithms to distinguish > which one to use. > > > > I agree with your conclusion about composite breaking backwards > compatibility. > > > > That said, I caution us against thinking about this problem only in terms > of a single use-case or protocol (TLS in this case). I want to keep this > discussion considering certificate use-cases that don=E2=80=99t have algo= rithm > negotiation mechanisms, for example code-signing, S/MIME, PKI smart cards= , > file encryption, whatever uses certificates in a way that isn=E2=80=99t = =E2=80=9Conline=E2=80=9D. > I would love to see the IETF provide a solution that applies to > certificates and signatures in general, rather than punting this problem = to > each protocol design team to solve independently. > > > > > > The primary rationale for doing PQ authentication now (or for that > matter composite authentication) is to be prepared for the day when QC > exists and we are therefore unable to rely on classical > algorithms. However, it's not useful to be prepared in that fashion > unless the algorithm that you are deploying is the one that is > eventually selected, because otherwise you just have to start over > once the selection is made. > > > > This conclusion =E2=80=93 that you=E2=80=99re only getting security value= once a PQ > exists, and any alg implementation we chose today will likely be obsolete > by then -- is probably right for browsers, but what about IoT devices > validating their firmware signature on boot? Or PKI smartcards? Or legal > contracts signed under eIDAS? Today we are creating certificates and > signed data objects that will outlive the advent of a QC. I think that > blurs closer to the =E2=80=9Cretrospective attack=E2=80=9D scenario that = you used for > motivating composite key exchange. > > > > While I=E2=80=99m aware that I=E2=80=99m using motivating examples from o= utside the IETF, > I think we have an opportunity to define a standard that is generic for a= ll > (or at least most) certificate use-cases. Let=E2=80=99s do the debate he= re about > carrying multiple signatures and the semantics of validating it, rather > than pushing it out to each protocol design team to debate independently. > > > > > > --- > > *Mike* Ounsworth *|* Office: +1 (613) 270-2873 > > > > *From:* Secdispatch *On Behalf Of *Eric > Rescorla > *Sent:* January 2, 2020 2:11 PM > *To:* Carrick Bartle > *Cc:* Dr. Pala ; Salz, Rich ; IETF > SecDispatch ; Stephen Farrell < > stephen.farrell@cs.tcd.ie> > *Subject:* [EXTERNAL]Re: [Secdispatch] Clarification Question for the > Comment from Eric Rescorla ( > > > > *WARNING:* This email originated outside of Entrust Datacard. > *DO NOT CLICK* links or attachments unless you trust the sender and know > the content is safe. > ------------------------------ > > > > > > On Thu, Jan 2, 2020 at 11:19 AM Carrick Bartle > wrote: > > What "start over" means in this case is get to the point where there is a > critical mass of client and server deployment, a process which takes time= . > > > > I see. > > > > I think not, at least for TLS. The consensus of implementors seems to be > that it's better to just cast composite algorithms as if they were new DH > groups, so there's not a huge amount of leverage in a generic mechanism. > > > > My understanding is that the Cloudflare-Google implementation generated > two separate shared secrets. Also this draft references several different > "ad hoc" approaches in implementations: > https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01. > > > > Well, yes, but on the wire it's packaged as a single group and key share. > > > > https://blog.cloudflare.com/the-tls-post-quantum-experiment/ > > > > -Ekr > > > > > > Carrick > > > > > > On Jan 2, 2020, at 10:50 AM, Eric Rescorla wrote: > > > > > > On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle > wrote: > > it's not useful to be prepared in that fashion > unless the algorithm that you are deploying is the one that is > eventually selected, because otherwise you just have to start over > once the selection is made. > > > > Just to be specific, do you mean, for instance, all the certificates with > the PQ algorithm that wasn't chosen would have to be revoked? > > > > Probably not. > > > > At a high level, there are two possible designs: > > > > 1. A certificate which has a composite signature in place of the classica= l > signature and thus cannot be validated by old clients. > > 2. A certificate which has a PQ signature somehow attached in a way that > it leaves the classical signature valid (as in an extension). > > > > In the former case, every server would need two certificates (one > composite and one classical) and use signature_algorithms to distinguish > which one to use. Once clients stopped liking the old PQ algorithm, then > those composite certificates would become irrelevant and just be unused. = In > the latter case, the certificates would continue to be valid and the clie= nt > could just ignore the PQ part of the signature. > > > > What "start over" means in this case is get to the point where there is a > critical mass of client and server deployment, a process which takes time= . > > > > the primary rationale for doing composite key exchange now is to > defend against retrospective attacks in case a quantum computer exists > in the future. In this setting, it isn't critically important to have > the PQ algorithm be the one we eventually land on, because each > connection is separately negotiated and as long as the PQ algorithm > has some security, you're getting benegit,. > > > > In that case, would it make sense to take the next step with drafting an > intended standard for composite key exchanges (that is PQ > algorithm-agnostic)? If not, why not? > > > > I think not, at least for TLS. The consensus of implementors seems to be > that it's better to just cast composite algorithms as if they were new DH > groups, so there's not a huge amount of leverage in a generic mechanism. > > > > -Ekr > > > > Carrick > > > > > > > > > > On Dec 25, 2019, at 5:57 PM, Eric Rescorla wrote: > > > > On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle > wrote: > > > How can it be true that it's too early to start developing a protocol > > for composite keys and signatures for Web PKI when Cloudflare and > > Google have already finished a round of experiments with composite key > > exchanges? Maybe I'm reading too much into it, but the existence of > > those experiments suggested to me that the need for composite/composite > > implementations was imminent. (I understand that the draft in question > > concerns signatures, not key exchanges, but apparently there isn't > > even a draft for the latter yet.) > > ISTM that these cases are pretty different, in a number of respects. > > First, the primary rationale for doing composite key exchange now is to > defend against retrospective attacks in case a quantum computer exists > in the future. In this setting, it isn't critically important to have > the PQ algorithm be the one we eventually land on, because each > connection is separately negotiated and as long as the PQ algorithm > has some security, you're getting benegit,. > > The primary rationale for doing PQ authentication now (or for that > matter composite authentication) is to be prepared for the day when QC > exists and we are therefore unable to rely on classical > algorithms. However, it's not useful to be prepared in that fashion > unless the algorithm that you are deploying is the one that is > eventually selected, because otherwise you just have to start over > once the selection is made. > > Moreover, in order to be truly prepared, what you need isn't > principally relying party deployment, but rather authenticating party > (in the case of the WebPKI, server-side) deployment. The reason for > this is that in the world where a QC exists, you don't have protection > until the relying party refuses to accept the classical credential > [0], and at present, any client which does so will effectively be > unable to communicate. And in order to make that happen, relying > parties will have to require a post-quantum algorithm (most likely as > a composite) and that's something I don't expect them to be willing to do > until there's widespread agreement on what that algorithm should be. > > > > If not now, when? After NIST crowns a winner? I don't see why it's > > necessary to wait that long given that the proposed solutions are > > algorithm-independent. And since the standardization process takes a > > while, won't waiting until then mean that there won't be a standard > > until after it's needed? > > No, i don't think so. > > For the reasons above, ISTM that real deployment will have to wait > until we have a selected algorithm. One could, as you suggest, deploy > some sort of multi-algorithm container, but IMO we will be far better > off just deploying new composite algorithms as if the were single > new algorithms, in the same way as we have done for key establishment. > > For this reason, I think we ought to wait until there is a consensus > PQ signature algorithm, at least for the WebPKI. > > -Ekr > > [0] This is why this kind of composite isn't helpful in the world > where a secret QC exists not. > > > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > > > > --000000000000bce8c6059ba39a99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike,

The context of this th= read is my comments at the mic that I didn't think this made much sense= for the WebPKI. I haven't fully thought through the non-WebPKI cases.<= br>

With that said, if you are concerned about lon= g-term signatures, I don't really understand the point of a hybrid sche= me, given that we don;'t really have that high confidence in any PQ sig= nature system other than hash signatures, so why not *just* use hash signat= ures?

-Ekr



=
On Wed, Ja= n 8, 2020 at 8:26 AM Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com> wrote:

Ekr said:

=C2=A0<= u>

In the former case, every= server would need two certificates (one composite and one classical) and u= se signature_algorithms to distinguish which one to use.

=C2=A0<= u>

I agree with y= our conclusion about composite breaking backwards compatibility.<= /u>

=C2=A0<= u>

That said, I c= aution us against thinking about this problem only in terms of a single use= -case or protocol (TLS in this case).=C2=A0 I want to keep this discussion = considering certificate use-cases that don=E2=80=99t have algorithm negotiation mechanisms, for example code-signing, S/MIME, PKI sm= art cards, file encryption, whatever uses certificates in a way that isn=E2= =80=99t =E2=80=9Conline=E2=80=9D.=C2=A0 I would love to see the IETF provid= e a solution that applies to certificates and signatures in general, rather than punting this problem to each protocol design team to solve ind= ependently.

=C2=A0<= u>

=C2=A0<= u>

The primary rationale for= doing PQ authentication now (or for that
matter composite authentication) is to be prepared for the day when QC
exists and we are therefore unable to rely on classical
algorithms. However, it's not useful to be prepared in that fashion
unless the algorithm that you are deploying is the one that is
eventually selected, because otherwise you just have to start over
once the selection is made.

=C2=A0

This conclusio= n =E2=80=93 that you=E2=80=99re only getting security value once a PQ exist= s, and any alg implementation we chose today will likely be obsolete by the= n -- is probably right for browsers, but what about IoT devices validating their firmware signature on boot? Or PKI smartcards?=C2=A0 Or l= egal contracts signed under eIDAS?=C2=A0 Today we are creating certificates= and signed data objects that will outlive the advent of a QC.=C2=A0 I thin= k that blurs closer to the =E2=80=9Cretrospective attack=E2=80=9D scenario that you used for motivating composite key exchange.

=C2=A0<= u>

While I=E2=80= =99m aware that I=E2=80=99m using motivating examples from outside the IETF= , I think we have an opportunity to define a standard that is generic for a= ll (or at least most) certificate use-cases.=C2=A0 Let=E2=80=99s do the deb= ate here about carrying multiple signatures and the semantics of validating it= , rather than pushing it out to each protocol design team to debate indepen= dently.

=C2=A0<= u>

=C2=A0<= u>

= ---

Mike Office: +1 (613) 270-2873

=C2=A0<= u>

From: Secdispatch <secdispatch-bounces@ietf.org= > On Behalf Of Eric Rescorla
Sent: January 2, 2020 2:11 PM
To: Carrick Bartle <cbartle891@icloud.com>
Cc: Dr. Pala <madwolf@openca.org>; Salz, Rich <rsalz@akamai.com>; IETF SecDispatch <<= a href=3D"mailto:secdispatch@ietf.org" target=3D"_blank">secdispatch@ietf.o= rg>; Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: [EXTERNAL]Re: [Secdispatch] Clarification Question for the = Comment from Eric Rescorla (

=C2=A0

WARNING: This email originated outside of En= trust Datacard.
DO = NOT CLICK links or attachments unless you trust the sender and k= now the content is safe.

=C2=A0

=C2=A0

On Thu, Jan 2, 2020 at 11:19 AM Carrick Bartle <<= a href=3D"mailto:cbartle891@icloud.com" target=3D"_blank">cbartle891@icloud= .com> wrote:

What "start over" means in this case is ge= t to the point where there is a critical mass of client and server deployme= nt, a process which takes time.

=C2=A0

I see.

=C2=A0

I think not, at least for TLS. The consensus of impl= ementors seems to be that it's better to just cast composite algorithms= as if they were new DH groups, so there's not a huge amount of leverag= e in a generic mechanism.

=C2=A0

My understanding is that the Cloudflare-Google imple= mentation generated two separate shared secrets. Also this draft references= several different "ad hoc" approaches in implementations:=C2=A0<= a href=3D"https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01" t= arget=3D"_blank">https://tools.ietf.org/html/draft-stebila-tls-hybrid-desig= n-01.

=C2=A0

Well, yes, but on the wire it's packaged as a si= ngle group and key share.

=C2=A0

=C2=A0

-Ekr

=C2=A0

=C2=A0

Carrick

=C2=A0



On Jan 2, 2020, at 10:50 AM, Eric Rescorla <ekr@rtfm.com> wrote:=

=C2=A0



On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle &l= t;cbartle891@icl= oud.com> wrote:

it's not useful to be prepared in that fashio= n
unless the algorithm that you are deploying is the one that is
eventually selected, because otherwise you just have to start over
once the selection is made.

=C2=A0

Just to be specific, do you mean, for instance, a= ll the certificates with the PQ algorithm that wasn't chosen would have= to be revoked?

=C2=A0

Probably not.=C2=A0

=C2=A0

At a high level, there are two possible designs:<= u>

=C2=A0

1. A certificate which has a composite signature = in place of the classical signature and thus cannot be validated by old cli= ents.

2. A certificate which has a PQ signature somehow= attached in a way that it leaves the classical signature valid (as in an e= xtension).

=C2=A0

In the former case, every server would need two c= ertificates (one composite and one classical) and use signature_algorithms = to distinguish which one to use. Once clients stopped liking the old PQ algorithm, then those composite certificates wou= ld become irrelevant and just be unused. In the latter case, the certificat= es would continue to be valid and the client could just ignore the PQ part = of the signature.

=C2=A0

What "start over" means in this case is= get to the point where there is a critical mass of client and server deplo= yment, a process which takes time.

=C2=A0

the primary rationale for doing composite key exc= hange now is to
defend against retrospective attacks in case a quantum computer exists
in the future. In this setting, it isn't critically important to have the PQ algorithm be the one we eventually land on, because each
connection is separately negotiated and as long as the PQ algorithm
has some security, you're getting benegit,.

=C2=A0

In that case, would it make sense to take the nex= t step with drafting an intended standard for composite key exchanges (that= is PQ algorithm-agnostic)? If not, why not?

=C2=A0

I think not, at least for TLS. The consensus of i= mplementors seems to be that it's better to just cast composite algorit= hms as if they were new DH groups, so there's not a huge amount of leverage in a generic mechanism.

=C2=A0

-Ekr

=C2=A0

Carrick

=C2=A0

=C2=A0

=C2=A0



On Dec 25, 2019, at 5:57 PM, Eric Rescorla <ekr@rtfm.com> wrote:=

=C2=A0

On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle &l= t;cbartle891@icl= oud.com> wrote:

> How can it be true that it's too early t= o start developing a protocol
> for composite keys and signatures for Web PKI when Cloudflare and
> Google have already finished a round of experiments with composite key=
> exchanges? Maybe I'm reading too much into it, but the existence o= f
> those experiments suggested to me that the need for composite/composit= e
> implementations was imminent. (I understand that the draft in question=
> concerns signatures, not key exchanges, but apparently there isn't=
> even a draft for the latter yet.)

ISTM that these cases are pretty different, in a number of respects.

First, the primary rationale for doing composite key exchange now is to
defend against retrospective attacks in case a quantum computer exists
in the future. In this setting, it isn't critically important to have the PQ algorithm be the one we eventually land on, because each
connection is separately negotiated and as long as the PQ algorithm
has some security, you're getting benegit,.

The primary rationale for doing PQ authentication now (or for that
matter composite authentication) is to be prepared for the day when QC
exists and we are therefore unable to rely on classical
algorithms. However, it's not useful to be prepared in that fashion
unless the algorithm that you are deploying is the one that is
eventually selected, because otherwise you just have to start over
once the selection is made.

Moreover, in order to be truly prepared, what you need isn't
principally relying party deployment, but rather authenticating party
(in the case of the WebPKI, server-side) deployment. The reason for
this is that in the world where a QC exists, you don't have protection<= br> until the relying party refuses to accept the classical credential
[0], and at present, any client which does so will effectively be
unable to communicate. And in order to make that happen, relying
parties will have to require a post-quantum algorithm (most likely as
a composite) and that's something I don't expect them to be willing= to do
until there's widespread agreement on what that algorithm should be.

> If not now, when? After NIST crowns a winner? I don't see why it&#= 39;s
> necessary to wait that long given that the proposed solutions are
> algorithm-independent. And since the standardization process takes a > while, won't waiting until then mean that there won't be a sta= ndard
> until after it's needed?

No, i don't think so.

For the reasons above, ISTM that real deployment will have to wait
until we have a selected algorithm. One could, as you suggest, deploy
some sort of multi-algorithm container, but IMO we will be far better
off just deploying new composite algorithms as if the were single
new algorithms, in the same way as we have done for key establishment.

For this reason, I think we ought to wait until there is a consensus
PQ signature algorithm, at least for the WebPKI.

-Ekr

[0] This is why this kind of composite isn't helpful in the world
where a secret QC exists not.

=C2=A0

=C2=A0

_______________________________________________ Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

=C2=A0

--000000000000bce8c6059ba39a99-- From nobody Wed Jan 8 09:10:29 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8211B12082F for ; Wed, 8 Jan 2020 09:10:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5z37P8oUbEI for ; Wed, 8 Jan 2020 09:10:23 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE5C12022A for ; Wed, 8 Jan 2020 09:10:23 -0800 (PST) IronPort-SDR: s9b15/jVwcEFYXp18e+wzcuAGd4Ix7h4C4hoK3MteIkJ1KZYQuG6q3l7SFHlLpLDRq542WfBiE CdkSOtxZ7WYA== X-IronPort-AV: E=Sophos;i="5.69,410,1571720400"; d="scan'208,217";a="7301385" Received: from pmspex04.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.51]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 08 Jan 2020 11:10:13 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by PMSPEX04.corporate.datacard.com (192.168.211.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Jan 2020 11:10:13 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Jan 2020 11:10:13 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nQaFByZEkRwsVSxI1Qf0qcE3MsstbsLr7Zk+uPiTanu4FTZVRrRgbtJSYrQbnnJj+IFN4e5cDA1Se/C2HRsj4t8thfp5uflmnA1LI4+FNskAx4iXu81rinnIlt6PMIsRxcfEKH3YCv9OF/HhmLLAdBqBfe0ESKbrdtQ9PTo+752wNZRptacA+0y6Pg01pZR5ixidSb9lc5EtJCCUMWbOJDaQ0BmqbIPXwx1HiGU/45zO0xG5niO+s6Tz4O6TjoCS++3elK9BM7WPkkReLLo3FTk5KQZmUMwihTcv5cMJvzJ7HvTUioq2I9mvxg8TDtBxxmkOIONueVOmxvpTqkwnVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5ezUzk6p0owTjyd7S812jkP5L83eGLaTFZ0NYJ2JMx8=; b=FhoYJmK9r7nhYqabs0F1bnLCNdDjlXLvQRiqIZhdkmet1UC+dRTSal3w8csBIlzBjn3zemP+2W19oy00zByCEkTUFr0Roq/9ISaBpxyMUhWgQRwXYFEcxmct3xYQYEMkCDcJ4nwUGglblasHuhuk6XOeGfEdxM27QfNVqPxOii/ljFyzeNUh9FQLpjty9D99yrMKDa7yN3TZCnBynBIyVBuUOg2qX0FfBRVPeJ0GCth4oXyCe4pD+EHBMDWvAL+5h4gDPD5snq4i+Mk4fyJJboLwLA6EHMn45H9n92hrNIGRRCFrEPKqQR4t5BIGnkkzxnsB1ebaGmWz6ihWcC70Lg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5ezUzk6p0owTjyd7S812jkP5L83eGLaTFZ0NYJ2JMx8=; b=VSLU64C5K23X5h0HnrUqsb1EuI4/DS0MBkdveLfOx6NbHSYFE6KIFrWOCH5Nkrp1P7L8C7AvvaIjSlVu1/1OkQxTs3Eau7aIxxcTqHagqKSzX/H9yWVP943ekk8W8FUd5vq+1xMno0oqxOeQUVXRDjqXka6rMLjgMuHtJaz3mOk= Received: from DM6PR11MB3883.namprd11.prod.outlook.com (10.255.61.32) by DM6PR11MB2827.namprd11.prod.outlook.com (20.176.100.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Wed, 8 Jan 2020 17:10:12 +0000 Received: from DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392]) by DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392%6]) with mapi id 15.20.2602.017; Wed, 8 Jan 2020 17:10:12 +0000 From: Mike Ounsworth To: Eric Rescorla CC: Carrick Bartle , "Dr. Pala" , "Salz, Rich" , IETF SecDispatch , Stephen Farrell Thread-Topic: [EXTERNAL]Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( Thread-Index: AQHVn3TqmuwoAaKifk6F5voq4PihRqeTq78AgDU9ZQCAAveOgIAMGfaAgAABkgCAAAgPgIAADmoAgAkfdvCAABSCgIAAAOgg Date: Wed, 8 Jan 2020 17:10:11 +0000 Message-ID: References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [204.124.81.102] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 234f3e31-5287-40d3-9a84-08d7945d9f50 x-ms-traffictypediagnostic: DM6PR11MB2827: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(366004)(346002)(396003)(51444003)(199004)(189003)(66446008)(64756008)(66556008)(478600001)(76116006)(966005)(52536014)(66476007)(4326008)(66946007)(33656002)(71200400001)(5660300002)(30864003)(2906002)(81166006)(316002)(7696005)(9686003)(81156014)(8936002)(26005)(53546011)(8676002)(6916009)(6506007)(55016002)(54906003)(186003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB2827; H:DM6PR11MB3883.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1Blp60p8fB/UrY4D3JVHA0l7y5c5W7A476nw7JnZfHVfh2gbxRI5p5NKB4dxF1LixlJIOLqsmsz4pJwonNaHbKOOrmAieamA15ILKATAVulWFdrdz/dSe8aeDYOQy6jNVkXIJKcQ0/U39D66D/oWFaAhLlihjCKlbD2lpuU5tRVKp91eYr6O2PcjbckbmPj5mvmdTpVJ7H9g67tfoAEeAwXJ9I5VKOuKTvq0cRLqc5O9nfFSUzjb7aKBkwGKp5NxEViC+Ost9FSMl+Dusrm1qqo+LNfQnEMuJXArVEv8kk0rXvVRXLJ5c1ZDePTH0QMIQaky5oIA3AiZD2OiW8EGY0QbVYr0cHa2a0UJKoy9wnGdvOgoHkEbvhLeeAdQLw3JmQl8WeMZqIJyS+R7ixfX9OWyYnPQOnxi2O8U4Ikxsx4gL8/RJv065P7BzNz1gcWbSnENTSy6AO6w3ylU7VFw6m9AbTznZtMxzrbLqcrCSVEBUzKurOBcsLLqVyTRakNnDpDKMst3ZL26kBBvpDZ8dPGDlSj9vAcPK42nqumhxma6540mlVHUNQ1umoSl/bez x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3883C9BD22D63B64B59928EC9B3E0DM6PR11MB3883namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 234f3e31-5287-40d3-9a84-08d7945d9f50 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 17:10:12.0194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gujTakzGh+g2NHUzI7kIzhcjUzjTi9ytquz6H/1iu6XOQyNfldVSezJ9iTQVboJCyU3SfM0EN9YA/1Ug4mMXwCuWg3rS5XR3uyAje4t2L4g6G7sTTH/ztG0rksfgzCgy X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2827 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla ( X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 17:10:27 -0000 --_000_DM6PR11MB3883C9BD22D63B64B59928EC9B3E0DM6PR11MB3883namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVhaCwgaGFzaC1iYXNlZCBpcyBwcm9iYWJseSBhIGdvb2QgZml0IGZvciBtYW55IHVzZS1jYXNl cy4NCg0KTXkgZGlzY3Vzc2lvbnMgd2l0aCBvdGhlciBwYXJ0aWVzIGFyb3VuZCBIQlMgaGF2ZSBn b3R0ZW4gc3R1Y2sgYXJvdW5kIHR3byBwb2ludHM6DQoNClN0YXRlbGVzcyB2cyBzdGF0ZWZ1bDog U3RhdGVsZXNzOiBiaWcmc2xvdy4gU3RhdGVmdWw6IGRpc3RyaWJ1dGluZyBrZXlzIGFjcm9zcyBs b2FkLWJhbGFuY2VycyBvciBzd2l0Y2gtb3ZlciB0byBhIGRpc2FzdGVyLXJlY292ZXJ5IHNpdGUg ZHVyaW5nIGEgcG93ZXItb3V0YWdlIGJlY29tZXMgdHJpY2t5LiAgVGhlcmUgYXJlIHNvbWUgTWVy a2xlIHRyZWUtc3BsaXR0aW5nIHRlY2huaXF1ZXMgdGhhdCBhbGxldmlhdGUgdGhpcyBhdCB0aGUg Y29zdCBvZiBuZWVkaW5nIHRvIGRlY2lkZSBhdCBrZXlnZW4gdGltZSBob3cgbWFueSBjb3BpZXMg b2YgdGhlIHByaXZhdGUga2V5IHlvdSB3YW50LiAgQWxzbywgaWYgeW91ciBlbmQtZW50aXR5IGhh cyB0aGUgcmlzayBvZiBhYnJ1cHQgcG93ZXItb2ZmcywgdGhlbiB5b3UgaGF2ZSB0aGUgcmlza3Mg ZGVzY3JpYmVkIGluIE1jR3JldyBldCBhbCDigJxTdGF0ZSBNYW5hZ2VtZW50IGZvciBIYXNoLUJh c2VkIFNpZ25hdHVyZXPigJ0uICBTbyB5b3UgcHJvYmFibHkgZG9u4oCZdCB3YW50IHN0YXRlZnVs IGVuZC1lbnRpdGllcy4gIERvIHlvdSB0aGVuIHdhbnQgaGV0ZXJvZ2Vub3VzIFBLSSBjaGFpbnMg cm9vdGVkIGluIEhCUyB3aXRoIHNvbWV0aGluZyBlbHNlIGJlbG93PyAgVGhlcmXigJlzIGp1c3Qg YSBsb3Qgb2YgdW5hbnN3ZXJlZCBxdWVzdGlvbnMuDQoNCg0KTWlncmF0aW9uOiBNYXggUGFsYSAo Y28tYXV0aG9yIG9uIHRoZSBDb21wb3NpdGUgU2lnbmF0dXJlcyBkcmFmdCkgd2FudHMgc29tZXRo aW5nIHdoZXJlIHlvdSBoYXZlIG11bHRpcGxlIHNpZ25hdHVyZXMgb24gYW4gb2JqZWN0LCBhbmQg dGhlIHZlcmlmaWVyIGNoZWNrcyBhcyBtYW55IGFzIHRoZXkgaGF2ZSBpbXBsZW1lbnRhdGlvbnMg b2YuICBZZXMsIHRoZXJl4oCZcyBhIGJyZWFraW5nIGNoYW5nZSB3aGVuIHlvdSBjdXQgb3ZlciB0 byB1c2luZyB0aGUgY29tcG9zaXRlIHN0cnVjdHVyZSwgYnV0IGFmdGVyIHRoYXQgeW91IGNhbiBk byBzdGFnZWQgbWlncmF0aW9ucyBvZiBjbGllbnQgc29mdHdhcmUgYW5kIHNpZ25pbmcgYWxnb3Jp dGhtcy4gIElmIHdpZGVseSBhZG9wdGVkLCB0aGlzIGNvdWxkIGV2ZW4gaGVscCB0aGUgbmV4dCB0 aW1lIHdlIG5lZWQgdG8gZG8gYSBTSEExIC0+IFNIQTIgdHlwZSBtaWdyYXRpb24gKGkuZS4gYSBn ZW5lcmljIGNvbXBvc2l0ZSBtZWNoYW5pc20gY291bGQgaGF2ZSB1dGlsaXR5IGJleW9uZCB0aGUg UFEgbWlncmF0aW9uKS4NCg0KLS0tDQpNaWtlIE91bnN3b3J0aCB8IE9mZmljZTogKzEgKDYxMykg MjcwLTI4NzMNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0KU2VudDogSmFu dWFyeSA4LCAyMDIwIDEwOjQ0IEFNDQpUbzogTWlrZSBPdW5zd29ydGggPE1pa2UuT3Vuc3dvcnRo QGVudHJ1c3RkYXRhY2FyZC5jb20+DQpDYzogQ2FycmljayBCYXJ0bGUgPGNiYXJ0bGU4OTFAaWNs b3VkLmNvbT47IERyLiBQYWxhIDxtYWR3b2xmQG9wZW5jYS5vcmc+OyBTYWx6LCBSaWNoIDxyc2Fs ekBha2FtYWkuY29tPjsgSUVURiBTZWNEaXNwYXRjaCA8c2VjZGlzcGF0Y2hAaWV0Zi5vcmc+OyBT dGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+DQpTdWJqZWN0OiBSZTog W0VYVEVSTkFMXVJlOiBbU2VjZGlzcGF0Y2hdIENsYXJpZmljYXRpb24gUXVlc3Rpb24gZm9yIHRo ZSBDb21tZW50IGZyb20gRXJpYyBSZXNjb3JsYSAoDQoNCk1pa2UsDQoNClRoZSBjb250ZXh0IG9m IHRoaXMgdGhyZWFkIGlzIG15IGNvbW1lbnRzIGF0IHRoZSBtaWMgdGhhdCBJIGRpZG4ndCB0aGlu ayB0aGlzIG1hZGUgbXVjaCBzZW5zZSBmb3IgdGhlIFdlYlBLSS4gSSBoYXZlbid0IGZ1bGx5IHRo b3VnaHQgdGhyb3VnaCB0aGUgbm9uLVdlYlBLSSBjYXNlcy4NCg0KV2l0aCB0aGF0IHNhaWQsIGlm IHlvdSBhcmUgY29uY2VybmVkIGFib3V0IGxvbmctdGVybSBzaWduYXR1cmVzLCBJIGRvbid0IHJl YWxseSB1bmRlcnN0YW5kIHRoZSBwb2ludCBvZiBhIGh5YnJpZCBzY2hlbWUsIGdpdmVuIHRoYXQg d2UgZG9uOyd0IHJlYWxseSBoYXZlIHRoYXQgaGlnaCBjb25maWRlbmNlIGluIGFueSBQUSBzaWdu YXR1cmUgc3lzdGVtIG90aGVyIHRoYW4gaGFzaCBzaWduYXR1cmVzLCBzbyB3aHkgbm90ICpqdXN0 KiB1c2UgaGFzaCBzaWduYXR1cmVzPw0KDQotRWtyDQoNCg0KDQpPbiBXZWQsIEphbiA4LCAyMDIw IGF0IDg6MjYgQU0gTWlrZSBPdW5zd29ydGggPE1pa2UuT3Vuc3dvcnRoQGVudHJ1c3RkYXRhY2Fy ZC5jb208bWFpbHRvOk1pa2UuT3Vuc3dvcnRoQGVudHJ1c3RkYXRhY2FyZC5jb20+PiB3cm90ZToN CkVrciBzYWlkOg0KDQpJbiB0aGUgZm9ybWVyIGNhc2UsIGV2ZXJ5IHNlcnZlciB3b3VsZCBuZWVk IHR3byBjZXJ0aWZpY2F0ZXMgKG9uZSBjb21wb3NpdGUgYW5kIG9uZSBjbGFzc2ljYWwpIGFuZCB1 c2Ugc2lnbmF0dXJlX2FsZ29yaXRobXMgdG8gZGlzdGluZ3Vpc2ggd2hpY2ggb25lIHRvIHVzZS4N Cg0KSSBhZ3JlZSB3aXRoIHlvdXIgY29uY2x1c2lvbiBhYm91dCBjb21wb3NpdGUgYnJlYWtpbmcg YmFja3dhcmRzIGNvbXBhdGliaWxpdHkuDQoNClRoYXQgc2FpZCwgSSBjYXV0aW9uIHVzIGFnYWlu c3QgdGhpbmtpbmcgYWJvdXQgdGhpcyBwcm9ibGVtIG9ubHkgaW4gdGVybXMgb2YgYSBzaW5nbGUg dXNlLWNhc2Ugb3IgcHJvdG9jb2wgKFRMUyBpbiB0aGlzIGNhc2UpLiAgSSB3YW50IHRvIGtlZXAg dGhpcyBkaXNjdXNzaW9uIGNvbnNpZGVyaW5nIGNlcnRpZmljYXRlIHVzZS1jYXNlcyB0aGF0IGRv buKAmXQgaGF2ZSBhbGdvcml0aG0gbmVnb3RpYXRpb24gbWVjaGFuaXNtcywgZm9yIGV4YW1wbGUg Y29kZS1zaWduaW5nLCBTL01JTUUsIFBLSSBzbWFydCBjYXJkcywgZmlsZSBlbmNyeXB0aW9uLCB3 aGF0ZXZlciB1c2VzIGNlcnRpZmljYXRlcyBpbiBhIHdheSB0aGF0IGlzbuKAmXQg4oCcb25saW5l 4oCdLiAgSSB3b3VsZCBsb3ZlIHRvIHNlZSB0aGUgSUVURiBwcm92aWRlIGEgc29sdXRpb24gdGhh dCBhcHBsaWVzIHRvIGNlcnRpZmljYXRlcyBhbmQgc2lnbmF0dXJlcyBpbiBnZW5lcmFsLCByYXRo ZXIgdGhhbiBwdW50aW5nIHRoaXMgcHJvYmxlbSB0byBlYWNoIHByb3RvY29sIGRlc2lnbiB0ZWFt IHRvIHNvbHZlIGluZGVwZW5kZW50bHkuDQoNCg0KVGhlIHByaW1hcnkgcmF0aW9uYWxlIGZvciBk b2luZyBQUSBhdXRoZW50aWNhdGlvbiBub3cgKG9yIGZvciB0aGF0DQptYXR0ZXIgY29tcG9zaXRl IGF1dGhlbnRpY2F0aW9uKSBpcyB0byBiZSBwcmVwYXJlZCBmb3IgdGhlIGRheSB3aGVuIFFDDQpl eGlzdHMgYW5kIHdlIGFyZSB0aGVyZWZvcmUgdW5hYmxlIHRvIHJlbHkgb24gY2xhc3NpY2FsDQph bGdvcml0aG1zLiBIb3dldmVyLCBpdCdzIG5vdCB1c2VmdWwgdG8gYmUgcHJlcGFyZWQgaW4gdGhh dCBmYXNoaW9uDQp1bmxlc3MgdGhlIGFsZ29yaXRobSB0aGF0IHlvdSBhcmUgZGVwbG95aW5nIGlz IHRoZSBvbmUgdGhhdCBpcw0KZXZlbnR1YWxseSBzZWxlY3RlZCwgYmVjYXVzZSBvdGhlcndpc2Ug eW91IGp1c3QgaGF2ZSB0byBzdGFydCBvdmVyDQpvbmNlIHRoZSBzZWxlY3Rpb24gaXMgbWFkZS4N Cg0KVGhpcyBjb25jbHVzaW9uIOKAkyB0aGF0IHlvdeKAmXJlIG9ubHkgZ2V0dGluZyBzZWN1cml0 eSB2YWx1ZSBvbmNlIGEgUFEgZXhpc3RzLCBhbmQgYW55IGFsZyBpbXBsZW1lbnRhdGlvbiB3ZSBj aG9zZSB0b2RheSB3aWxsIGxpa2VseSBiZSBvYnNvbGV0ZSBieSB0aGVuIC0tIGlzIHByb2JhYmx5 IHJpZ2h0IGZvciBicm93c2VycywgYnV0IHdoYXQgYWJvdXQgSW9UIGRldmljZXMgdmFsaWRhdGlu ZyB0aGVpciBmaXJtd2FyZSBzaWduYXR1cmUgb24gYm9vdD8gT3IgUEtJIHNtYXJ0Y2FyZHM/ICBP ciBsZWdhbCBjb250cmFjdHMgc2lnbmVkIHVuZGVyIGVJREFTPyAgVG9kYXkgd2UgYXJlIGNyZWF0 aW5nIGNlcnRpZmljYXRlcyBhbmQgc2lnbmVkIGRhdGEgb2JqZWN0cyB0aGF0IHdpbGwgb3V0bGl2 ZSB0aGUgYWR2ZW50IG9mIGEgUUMuICBJIHRoaW5rIHRoYXQgYmx1cnMgY2xvc2VyIHRvIHRoZSDi gJxyZXRyb3NwZWN0aXZlIGF0dGFja+KAnSBzY2VuYXJpbyB0aGF0IHlvdSB1c2VkIGZvciBtb3Rp dmF0aW5nIGNvbXBvc2l0ZSBrZXkgZXhjaGFuZ2UuDQoNCldoaWxlIEnigJltIGF3YXJlIHRoYXQg SeKAmW0gdXNpbmcgbW90aXZhdGluZyBleGFtcGxlcyBmcm9tIG91dHNpZGUgdGhlIElFVEYsIEkg dGhpbmsgd2UgaGF2ZSBhbiBvcHBvcnR1bml0eSB0byBkZWZpbmUgYSBzdGFuZGFyZCB0aGF0IGlz IGdlbmVyaWMgZm9yIGFsbCAob3IgYXQgbGVhc3QgbW9zdCkgY2VydGlmaWNhdGUgdXNlLWNhc2Vz LiAgTGV04oCZcyBkbyB0aGUgZGViYXRlIGhlcmUgYWJvdXQgY2FycnlpbmcgbXVsdGlwbGUgc2ln bmF0dXJlcyBhbmQgdGhlIHNlbWFudGljcyBvZiB2YWxpZGF0aW5nIGl0LCByYXRoZXIgdGhhbiBw dXNoaW5nIGl0IG91dCB0byBlYWNoIHByb3RvY29sIGRlc2lnbiB0ZWFtIHRvIGRlYmF0ZSBpbmRl cGVuZGVudGx5Lg0KDQoNCi0tLQ0KTWlrZSBPdW5zd29ydGggfCBPZmZpY2U6ICsxICg2MTMpIDI3 MC0yODczDQoNCkZyb206IFNlY2Rpc3BhdGNoIDxzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEVyaWMg UmVzY29ybGENClNlbnQ6IEphbnVhcnkgMiwgMjAyMCAyOjExIFBNDQpUbzogQ2FycmljayBCYXJ0 bGUgPGNiYXJ0bGU4OTFAaWNsb3VkLmNvbTxtYWlsdG86Y2JhcnRsZTg5MUBpY2xvdWQuY29tPj4N CkNjOiBEci4gUGFsYSA8bWFkd29sZkBvcGVuY2Eub3JnPG1haWx0bzptYWR3b2xmQG9wZW5jYS5v cmc+PjsgU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFpLmNv bT4+OyBJRVRGIFNlY0Rpc3BhdGNoIDxzZWNkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86c2VjZGlz cGF0Y2hAaWV0Zi5vcmc+PjsgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNk LmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4NClN1YmplY3Q6IFtFWFRFUk5B TF1SZTogW1NlY2Rpc3BhdGNoXSBDbGFyaWZpY2F0aW9uIFF1ZXN0aW9uIGZvciB0aGUgQ29tbWVu dCBmcm9tIEVyaWMgUmVzY29ybGEgKA0KDQpXQVJOSU5HOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQg b3V0c2lkZSBvZiBFbnRydXN0IERhdGFjYXJkLg0KRE8gTk9UIENMSUNLIGxpbmtzIG9yIGF0dGFj aG1lbnRzIHVubGVzcyB5b3UgdHJ1c3QgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBp cyBzYWZlLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQpPbiBUaHUsIEph biAyLCAyMDIwIGF0IDExOjE5IEFNIENhcnJpY2sgQmFydGxlIDxjYmFydGxlODkxQGljbG91ZC5j b208bWFpbHRvOmNiYXJ0bGU4OTFAaWNsb3VkLmNvbT4+IHdyb3RlOg0KV2hhdCAic3RhcnQgb3Zl ciIgbWVhbnMgaW4gdGhpcyBjYXNlIGlzIGdldCB0byB0aGUgcG9pbnQgd2hlcmUgdGhlcmUgaXMg YSBjcml0aWNhbCBtYXNzIG9mIGNsaWVudCBhbmQgc2VydmVyIGRlcGxveW1lbnQsIGEgcHJvY2Vz cyB3aGljaCB0YWtlcyB0aW1lLg0KDQpJIHNlZS4NCg0KSSB0aGluayBub3QsIGF0IGxlYXN0IGZv ciBUTFMuIFRoZSBjb25zZW5zdXMgb2YgaW1wbGVtZW50b3JzIHNlZW1zIHRvIGJlIHRoYXQgaXQn cyBiZXR0ZXIgdG8ganVzdCBjYXN0IGNvbXBvc2l0ZSBhbGdvcml0aG1zIGFzIGlmIHRoZXkgd2Vy ZSBuZXcgREggZ3JvdXBzLCBzbyB0aGVyZSdzIG5vdCBhIGh1Z2UgYW1vdW50IG9mIGxldmVyYWdl IGluIGEgZ2VuZXJpYyBtZWNoYW5pc20uDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUg Q2xvdWRmbGFyZS1Hb29nbGUgaW1wbGVtZW50YXRpb24gZ2VuZXJhdGVkIHR3byBzZXBhcmF0ZSBz aGFyZWQgc2VjcmV0cy4gQWxzbyB0aGlzIGRyYWZ0IHJlZmVyZW5jZXMgc2V2ZXJhbCBkaWZmZXJl bnQgImFkIGhvYyIgYXBwcm9hY2hlcyBpbiBpbXBsZW1lbnRhdGlvbnM6IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zdGViaWxhLXRscy1oeWJyaWQtZGVzaWduLTAxLg0KDQpXZWxs LCB5ZXMsIGJ1dCBvbiB0aGUgd2lyZSBpdCdzIHBhY2thZ2VkIGFzIGEgc2luZ2xlIGdyb3VwIGFu ZCBrZXkgc2hhcmUuDQoNCmh0dHBzOi8vYmxvZy5jbG91ZGZsYXJlLmNvbS90aGUtdGxzLXBvc3Qt cXVhbnR1bS1leHBlcmltZW50Lw0KDQotRWtyDQoNCg0KQ2Fycmljaw0KDQoNCk9uIEphbiAyLCAy MDIwLCBhdCAxMDo1MCBBTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JA cnRmbS5jb20+PiB3cm90ZToNCg0KDQpPbiBUaHUsIEphbiAyLCAyMDIwIGF0IDEwOjQ1IEFNIENh cnJpY2sgQmFydGxlIDxjYmFydGxlODkxQGljbG91ZC5jb208bWFpbHRvOmNiYXJ0bGU4OTFAaWNs b3VkLmNvbT4+IHdyb3RlOg0KaXQncyBub3QgdXNlZnVsIHRvIGJlIHByZXBhcmVkIGluIHRoYXQg ZmFzaGlvbg0KdW5sZXNzIHRoZSBhbGdvcml0aG0gdGhhdCB5b3UgYXJlIGRlcGxveWluZyBpcyB0 aGUgb25lIHRoYXQgaXMNCmV2ZW50dWFsbHkgc2VsZWN0ZWQsIGJlY2F1c2Ugb3RoZXJ3aXNlIHlv dSBqdXN0IGhhdmUgdG8gc3RhcnQgb3Zlcg0Kb25jZSB0aGUgc2VsZWN0aW9uIGlzIG1hZGUuDQoN Ckp1c3QgdG8gYmUgc3BlY2lmaWMsIGRvIHlvdSBtZWFuLCBmb3IgaW5zdGFuY2UsIGFsbCB0aGUg Y2VydGlmaWNhdGVzIHdpdGggdGhlIFBRIGFsZ29yaXRobSB0aGF0IHdhc24ndCBjaG9zZW4gd291 bGQgaGF2ZSB0byBiZSByZXZva2VkPw0KDQpQcm9iYWJseSBub3QuDQoNCkF0IGEgaGlnaCBsZXZl bCwgdGhlcmUgYXJlIHR3byBwb3NzaWJsZSBkZXNpZ25zOg0KDQoxLiBBIGNlcnRpZmljYXRlIHdo aWNoIGhhcyBhIGNvbXBvc2l0ZSBzaWduYXR1cmUgaW4gcGxhY2Ugb2YgdGhlIGNsYXNzaWNhbCBz aWduYXR1cmUgYW5kIHRodXMgY2Fubm90IGJlIHZhbGlkYXRlZCBieSBvbGQgY2xpZW50cy4NCjIu IEEgY2VydGlmaWNhdGUgd2hpY2ggaGFzIGEgUFEgc2lnbmF0dXJlIHNvbWVob3cgYXR0YWNoZWQg aW4gYSB3YXkgdGhhdCBpdCBsZWF2ZXMgdGhlIGNsYXNzaWNhbCBzaWduYXR1cmUgdmFsaWQgKGFz IGluIGFuIGV4dGVuc2lvbikuDQoNCkluIHRoZSBmb3JtZXIgY2FzZSwgZXZlcnkgc2VydmVyIHdv dWxkIG5lZWQgdHdvIGNlcnRpZmljYXRlcyAob25lIGNvbXBvc2l0ZSBhbmQgb25lIGNsYXNzaWNh bCkgYW5kIHVzZSBzaWduYXR1cmVfYWxnb3JpdGhtcyB0byBkaXN0aW5ndWlzaCB3aGljaCBvbmUg dG8gdXNlLiBPbmNlIGNsaWVudHMgc3RvcHBlZCBsaWtpbmcgdGhlIG9sZCBQUSBhbGdvcml0aG0s IHRoZW4gdGhvc2UgY29tcG9zaXRlIGNlcnRpZmljYXRlcyB3b3VsZCBiZWNvbWUgaXJyZWxldmFu dCBhbmQganVzdCBiZSB1bnVzZWQuIEluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIGNlcnRpZmljYXRl cyB3b3VsZCBjb250aW51ZSB0byBiZSB2YWxpZCBhbmQgdGhlIGNsaWVudCBjb3VsZCBqdXN0IGln bm9yZSB0aGUgUFEgcGFydCBvZiB0aGUgc2lnbmF0dXJlLg0KDQpXaGF0ICJzdGFydCBvdmVyIiBt ZWFucyBpbiB0aGlzIGNhc2UgaXMgZ2V0IHRvIHRoZSBwb2ludCB3aGVyZSB0aGVyZSBpcyBhIGNy aXRpY2FsIG1hc3Mgb2YgY2xpZW50IGFuZCBzZXJ2ZXIgZGVwbG95bWVudCwgYSBwcm9jZXNzIHdo aWNoIHRha2VzIHRpbWUuDQoNCnRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgZG9pbmcgY29tcG9z aXRlIGtleSBleGNoYW5nZSBub3cgaXMgdG8NCmRlZmVuZCBhZ2FpbnN0IHJldHJvc3BlY3RpdmUg YXR0YWNrcyBpbiBjYXNlIGEgcXVhbnR1bSBjb21wdXRlciBleGlzdHMNCmluIHRoZSBmdXR1cmUu IEluIHRoaXMgc2V0dGluZywgaXQgaXNuJ3QgY3JpdGljYWxseSBpbXBvcnRhbnQgdG8gaGF2ZQ0K dGhlIFBRIGFsZ29yaXRobSBiZSB0aGUgb25lIHdlIGV2ZW50dWFsbHkgbGFuZCBvbiwgYmVjYXVz ZSBlYWNoDQpjb25uZWN0aW9uIGlzIHNlcGFyYXRlbHkgbmVnb3RpYXRlZCBhbmQgYXMgbG9uZyBh cyB0aGUgUFEgYWxnb3JpdGhtDQpoYXMgc29tZSBzZWN1cml0eSwgeW91J3JlIGdldHRpbmcgYmVu ZWdpdCwuDQoNCkluIHRoYXQgY2FzZSwgd291bGQgaXQgbWFrZSBzZW5zZSB0byB0YWtlIHRoZSBu ZXh0IHN0ZXAgd2l0aCBkcmFmdGluZyBhbiBpbnRlbmRlZCBzdGFuZGFyZCBmb3IgY29tcG9zaXRl IGtleSBleGNoYW5nZXMgKHRoYXQgaXMgUFEgYWxnb3JpdGhtLWFnbm9zdGljKT8gSWYgbm90LCB3 aHkgbm90Pw0KDQpJIHRoaW5rIG5vdCwgYXQgbGVhc3QgZm9yIFRMUy4gVGhlIGNvbnNlbnN1cyBv ZiBpbXBsZW1lbnRvcnMgc2VlbXMgdG8gYmUgdGhhdCBpdCdzIGJldHRlciB0byBqdXN0IGNhc3Qg Y29tcG9zaXRlIGFsZ29yaXRobXMgYXMgaWYgdGhleSB3ZXJlIG5ldyBESCBncm91cHMsIHNvIHRo ZXJlJ3Mgbm90IGEgaHVnZSBhbW91bnQgb2YgbGV2ZXJhZ2UgaW4gYSBnZW5lcmljIG1lY2hhbmlz bS4NCg0KLUVrcg0KDQpDYXJyaWNrDQoNCg0KDQoNCk9uIERlYyAyNSwgMjAxOSwgYXQgNTo1NyBQ TSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90 ZToNCg0KT24gTW9uLCBEZWMgMjMsIDIwMTkgYXQgODozOCBQTSBDYXJyaWNrIEJhcnRsZSA8Y2Jh cnRsZTg5MUBpY2xvdWQuY29tPG1haWx0bzpjYmFydGxlODkxQGljbG91ZC5jb20+PiB3cm90ZToN Cj4gSG93IGNhbiBpdCBiZSB0cnVlIHRoYXQgaXQncyB0b28gZWFybHkgdG8gc3RhcnQgZGV2ZWxv cGluZyBhIHByb3RvY29sDQo+IGZvciBjb21wb3NpdGUga2V5cyBhbmQgc2lnbmF0dXJlcyBmb3Ig V2ViIFBLSSB3aGVuIENsb3VkZmxhcmUgYW5kDQo+IEdvb2dsZSBoYXZlIGFscmVhZHkgZmluaXNo ZWQgYSByb3VuZCBvZiBleHBlcmltZW50cyB3aXRoIGNvbXBvc2l0ZSBrZXkNCj4gZXhjaGFuZ2Vz PyBNYXliZSBJJ20gcmVhZGluZyB0b28gbXVjaCBpbnRvIGl0LCBidXQgdGhlIGV4aXN0ZW5jZSBv Zg0KPiB0aG9zZSBleHBlcmltZW50cyBzdWdnZXN0ZWQgdG8gbWUgdGhhdCB0aGUgbmVlZCBmb3Ig Y29tcG9zaXRlL2NvbXBvc2l0ZQ0KPiBpbXBsZW1lbnRhdGlvbnMgd2FzIGltbWluZW50LiAoSSB1 bmRlcnN0YW5kIHRoYXQgdGhlIGRyYWZ0IGluIHF1ZXN0aW9uDQo+IGNvbmNlcm5zIHNpZ25hdHVy ZXMsIG5vdCBrZXkgZXhjaGFuZ2VzLCBidXQgYXBwYXJlbnRseSB0aGVyZSBpc24ndA0KPiBldmVu IGEgZHJhZnQgZm9yIHRoZSBsYXR0ZXIgeWV0LikNCg0KSVNUTSB0aGF0IHRoZXNlIGNhc2VzIGFy ZSBwcmV0dHkgZGlmZmVyZW50LCBpbiBhIG51bWJlciBvZiByZXNwZWN0cy4NCg0KRmlyc3QsIHRo ZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgZG9pbmcgY29tcG9zaXRlIGtleSBleGNoYW5nZSBub3cg aXMgdG8NCmRlZmVuZCBhZ2FpbnN0IHJldHJvc3BlY3RpdmUgYXR0YWNrcyBpbiBjYXNlIGEgcXVh bnR1bSBjb21wdXRlciBleGlzdHMNCmluIHRoZSBmdXR1cmUuIEluIHRoaXMgc2V0dGluZywgaXQg aXNuJ3QgY3JpdGljYWxseSBpbXBvcnRhbnQgdG8gaGF2ZQ0KdGhlIFBRIGFsZ29yaXRobSBiZSB0 aGUgb25lIHdlIGV2ZW50dWFsbHkgbGFuZCBvbiwgYmVjYXVzZSBlYWNoDQpjb25uZWN0aW9uIGlz IHNlcGFyYXRlbHkgbmVnb3RpYXRlZCBhbmQgYXMgbG9uZyBhcyB0aGUgUFEgYWxnb3JpdGhtDQpo YXMgc29tZSBzZWN1cml0eSwgeW91J3JlIGdldHRpbmcgYmVuZWdpdCwuDQoNClRoZSBwcmltYXJ5 IHJhdGlvbmFsZSBmb3IgZG9pbmcgUFEgYXV0aGVudGljYXRpb24gbm93IChvciBmb3IgdGhhdA0K bWF0dGVyIGNvbXBvc2l0ZSBhdXRoZW50aWNhdGlvbikgaXMgdG8gYmUgcHJlcGFyZWQgZm9yIHRo ZSBkYXkgd2hlbiBRQw0KZXhpc3RzIGFuZCB3ZSBhcmUgdGhlcmVmb3JlIHVuYWJsZSB0byByZWx5 IG9uIGNsYXNzaWNhbA0KYWxnb3JpdGhtcy4gSG93ZXZlciwgaXQncyBub3QgdXNlZnVsIHRvIGJl IHByZXBhcmVkIGluIHRoYXQgZmFzaGlvbg0KdW5sZXNzIHRoZSBhbGdvcml0aG0gdGhhdCB5b3Ug YXJlIGRlcGxveWluZyBpcyB0aGUgb25lIHRoYXQgaXMNCmV2ZW50dWFsbHkgc2VsZWN0ZWQsIGJl Y2F1c2Ugb3RoZXJ3aXNlIHlvdSBqdXN0IGhhdmUgdG8gc3RhcnQgb3Zlcg0Kb25jZSB0aGUgc2Vs ZWN0aW9uIGlzIG1hZGUuDQoNCk1vcmVvdmVyLCBpbiBvcmRlciB0byBiZSB0cnVseSBwcmVwYXJl ZCwgd2hhdCB5b3UgbmVlZCBpc24ndA0KcHJpbmNpcGFsbHkgcmVseWluZyBwYXJ0eSBkZXBsb3lt ZW50LCBidXQgcmF0aGVyIGF1dGhlbnRpY2F0aW5nIHBhcnR5DQooaW4gdGhlIGNhc2Ugb2YgdGhl IFdlYlBLSSwgc2VydmVyLXNpZGUpIGRlcGxveW1lbnQuIFRoZSByZWFzb24gZm9yDQp0aGlzIGlz IHRoYXQgaW4gdGhlIHdvcmxkIHdoZXJlIGEgUUMgZXhpc3RzLCB5b3UgZG9uJ3QgaGF2ZSBwcm90 ZWN0aW9uDQp1bnRpbCB0aGUgcmVseWluZyBwYXJ0eSByZWZ1c2VzIHRvIGFjY2VwdCB0aGUgY2xh c3NpY2FsIGNyZWRlbnRpYWwNClswXSwgYW5kIGF0IHByZXNlbnQsIGFueSBjbGllbnQgd2hpY2gg ZG9lcyBzbyB3aWxsIGVmZmVjdGl2ZWx5IGJlDQp1bmFibGUgdG8gY29tbXVuaWNhdGUuIEFuZCBp biBvcmRlciB0byBtYWtlIHRoYXQgaGFwcGVuLCByZWx5aW5nDQpwYXJ0aWVzIHdpbGwgaGF2ZSB0 byByZXF1aXJlIGEgcG9zdC1xdWFudHVtIGFsZ29yaXRobSAobW9zdCBsaWtlbHkgYXMNCmEgY29t cG9zaXRlKSBhbmQgdGhhdCdzIHNvbWV0aGluZyBJIGRvbid0IGV4cGVjdCB0aGVtIHRvIGJlIHdp bGxpbmcgdG8gZG8NCnVudGlsIHRoZXJlJ3Mgd2lkZXNwcmVhZCBhZ3JlZW1lbnQgb24gd2hhdCB0 aGF0IGFsZ29yaXRobSBzaG91bGQgYmUuDQoNCg0KPiBJZiBub3Qgbm93LCB3aGVuPyBBZnRlciBO SVNUIGNyb3ducyBhIHdpbm5lcj8gSSBkb24ndCBzZWUgd2h5IGl0J3MNCj4gbmVjZXNzYXJ5IHRv IHdhaXQgdGhhdCBsb25nIGdpdmVuIHRoYXQgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucyBhcmUNCj4g YWxnb3JpdGhtLWluZGVwZW5kZW50LiBBbmQgc2luY2UgdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9j ZXNzIHRha2VzIGENCj4gd2hpbGUsIHdvbid0IHdhaXRpbmcgdW50aWwgdGhlbiBtZWFuIHRoYXQg dGhlcmUgd29uJ3QgYmUgYSBzdGFuZGFyZA0KPiB1bnRpbCBhZnRlciBpdCdzIG5lZWRlZD8NCg0K Tm8sIGkgZG9uJ3QgdGhpbmsgc28uDQoNCkZvciB0aGUgcmVhc29ucyBhYm92ZSwgSVNUTSB0aGF0 IHJlYWwgZGVwbG95bWVudCB3aWxsIGhhdmUgdG8gd2FpdA0KdW50aWwgd2UgaGF2ZSBhIHNlbGVj dGVkIGFsZ29yaXRobS4gT25lIGNvdWxkLCBhcyB5b3Ugc3VnZ2VzdCwgZGVwbG95DQpzb21lIHNv cnQgb2YgbXVsdGktYWxnb3JpdGhtIGNvbnRhaW5lciwgYnV0IElNTyB3ZSB3aWxsIGJlIGZhciBi ZXR0ZXINCm9mZiBqdXN0IGRlcGxveWluZyBuZXcgY29tcG9zaXRlIGFsZ29yaXRobXMgYXMgaWYg dGhlIHdlcmUgc2luZ2xlDQpuZXcgYWxnb3JpdGhtcywgaW4gdGhlIHNhbWUgd2F5IGFzIHdlIGhh dmUgZG9uZSBmb3Iga2V5IGVzdGFibGlzaG1lbnQuDQoNCkZvciB0aGlzIHJlYXNvbiwgSSB0aGlu ayB3ZSBvdWdodCB0byB3YWl0IHVudGlsIHRoZXJlIGlzIGEgY29uc2Vuc3VzDQpQUSBzaWduYXR1 cmUgYWxnb3JpdGhtLCBhdCBsZWFzdCBmb3IgdGhlIFdlYlBLSS4NCg0KLUVrcg0KDQpbMF0gVGhp cyBpcyB3aHkgdGhpcyBraW5kIG9mIGNvbXBvc2l0ZSBpc24ndCBoZWxwZnVsIGluIHRoZSB3b3Js ZA0Kd2hlcmUgYSBzZWNyZXQgUUMgZXhpc3RzIG5vdC4NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpT ZWNkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86U2VjZGlzcGF0Y2hAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQoNCg== --_000_DM6PR11MB3883C9BD22D63B64B59928EC9B3E0DM6PR11MB3883namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlh bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojNzAzMEEwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzAzMEEwIj5ZZWFoLCBoYXNoLWJhc2VkIGlzIHBy b2JhYmx5IGEgZ29vZCBmaXQgZm9yIG1hbnkgdXNlLWNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzAzMEEwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzcwMzBBMCI+TXkgZGlzY3Vzc2lvbnMgd2l0aCBvdGhlciBwYXJ0aWVzIGFyb3Vu ZCBIQlMgaGF2ZSBnb3R0ZW4gc3R1Y2sgYXJvdW5kIHR3byBwb2ludHM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojNzAzMEEwIj5TdGF0ZWxlc3MgdnMgc3RhdGVmdWw6IFN0YXRlbGVzczog YmlnJmFtcDtzbG93LiBTdGF0ZWZ1bDogZGlzdHJpYnV0aW5nIGtleXMgYWNyb3NzIGxvYWQtYmFs YW5jZXJzIG9yIHN3aXRjaC1vdmVyIHRvIGEgZGlzYXN0ZXItcmVjb3Zlcnkgc2l0ZSBkdXJpbmcg YSBwb3dlci1vdXRhZ2UgYmVjb21lcyB0cmlja3kuICZuYnNwO1RoZXJlIGFyZSBzb21lIE1lcmts ZSB0cmVlLXNwbGl0dGluZw0KIHRlY2huaXF1ZXMgdGhhdCBhbGxldmlhdGUgdGhpcyBhdCB0aGUg Y29zdCBvZiBuZWVkaW5nIHRvIGRlY2lkZSBhdCBrZXlnZW4gdGltZSBob3cgbWFueSBjb3BpZXMg b2YgdGhlIHByaXZhdGUga2V5IHlvdSB3YW50LiZuYnNwOyBBbHNvLCBpZiB5b3VyIGVuZC1lbnRp dHkgaGFzIHRoZSByaXNrIG9mIGFicnVwdCBwb3dlci1vZmZzLCB0aGVuIHlvdSBoYXZlIHRoZSBy aXNrcyBkZXNjcmliZWQgaW4gTWNHcmV3IGV0IGFsIOKAnFN0YXRlIE1hbmFnZW1lbnQgZm9yDQog SGFzaC1CYXNlZCBTaWduYXR1cmVz4oCdLiZuYnNwOyBTbyB5b3UgcHJvYmFibHkgZG9u4oCZdCB3 YW50IHN0YXRlZnVsIGVuZC1lbnRpdGllcy4mbmJzcDsgRG8geW91IHRoZW4gd2FudCBoZXRlcm9n ZW5vdXMgUEtJIGNoYWlucyByb290ZWQgaW4gSEJTIHdpdGggc29tZXRoaW5nIGVsc2UgYmVsb3c/ Jm5ic3A7IFRoZXJl4oCZcyBqdXN0IGEgbG90IG9mIHVuYW5zd2VyZWQgcXVlc3Rpb25zLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPk1p Z3JhdGlvbjogTWF4IFBhbGEgKGNvLWF1dGhvciBvbiB0aGUgQ29tcG9zaXRlIFNpZ25hdHVyZXMg ZHJhZnQpIHdhbnRzIHNvbWV0aGluZyB3aGVyZSB5b3UgaGF2ZSBtdWx0aXBsZSBzaWduYXR1cmVz IG9uIGFuIG9iamVjdCwgYW5kIHRoZSB2ZXJpZmllciBjaGVja3MgYXMgbWFueSBhcyB0aGV5IGhh dmUgaW1wbGVtZW50YXRpb25zIG9mLiZuYnNwOyBZZXMsIHRoZXJl4oCZcw0KIGEgYnJlYWtpbmcg Y2hhbmdlIHdoZW4geW91IGN1dCBvdmVyIHRvIHVzaW5nIHRoZSBjb21wb3NpdGUgc3RydWN0dXJl LCBidXQgYWZ0ZXIgdGhhdCB5b3UgY2FuIGRvIHN0YWdlZCBtaWdyYXRpb25zIG9mIGNsaWVudCBz b2Z0d2FyZSBhbmQgc2lnbmluZyBhbGdvcml0aG1zLiZuYnNwOyBJZiB3aWRlbHkgYWRvcHRlZCwg dGhpcyBjb3VsZCBldmVuIGhlbHAgdGhlIG5leHQgdGltZSB3ZSBuZWVkIHRvIGRvIGEgU0hBMSAt Jmd0OyBTSEEyIHR5cGUgbWlncmF0aW9uDQogKGkuZS4gYSBnZW5lcmljIGNvbXBvc2l0ZSBtZWNo YW5pc20gY291bGQgaGF2ZSB1dGlsaXR5IGJleW9uZCB0aGUgUFEgbWlncmF0aW9uKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojNzAzMEEwIj4tLS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzcwMzBBMCI+TWlrZTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MDMwQTAiPiBP dW5zd29ydGgNCjxiPnw8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4NCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwMzBBMCI+T2ZmaWNlPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpncmF5Ij46ICYjNDM7MSAoNjEzKSAyNzAtMjg3Mzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6IzcwMzBBMCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBFcmljIFJlc2NvcmxhICZsdDtl a3JAcnRmbS5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBKYW51YXJ5IDgsIDIwMjAgMTA6NDQg QU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgT3Vuc3dvcnRoICZsdDtNaWtlLk91bnN3b3J0aEBlbnRy dXN0ZGF0YWNhcmQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2FycmljayBCYXJ0bGUgJmx0O2Ni YXJ0bGU4OTFAaWNsb3VkLmNvbSZndDs7IERyLiBQYWxhICZsdDttYWR3b2xmQG9wZW5jYS5vcmcm Z3Q7OyBTYWx6LCBSaWNoICZsdDtyc2FsekBha2FtYWkuY29tJmd0OzsgSUVURiBTZWNEaXNwYXRj aCAmbHQ7c2VjZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7OyBTdGVwaGVuIEZhcnJlbGwgJmx0O3N0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWUmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRVhURVJO QUxdUmU6IFtTZWNkaXNwYXRjaF0gQ2xhcmlmaWNhdGlvbiBRdWVzdGlvbiBmb3IgdGhlIENvbW1l bnQgZnJvbSBFcmljIFJlc2NvcmxhICg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NaWtlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgY29udGV4dCBvZiB0aGlzIHRocmVhZCBpcyBteSBjb21tZW50cyBhdCB0aGUg bWljIHRoYXQgSSBkaWRuJ3QgdGhpbmsgdGhpcyBtYWRlIG11Y2ggc2Vuc2UgZm9yIHRoZSBXZWJQ S0kuIEkgaGF2ZW4ndCBmdWxseSB0aG91Z2h0IHRocm91Z2ggdGhlIG5vbi1XZWJQS0kgY2FzZXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldp dGggdGhhdCBzYWlkLCBpZiB5b3UgYXJlIGNvbmNlcm5lZCBhYm91dCBsb25nLXRlcm0gc2lnbmF0 dXJlcywgSSBkb24ndCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgcG9pbnQgb2YgYSBoeWJyaWQgc2No ZW1lLCBnaXZlbiB0aGF0IHdlIGRvbjsndCByZWFsbHkgaGF2ZSB0aGF0IGhpZ2ggY29uZmlkZW5j ZSBpbiBhbnkgUFEgc2lnbmF0dXJlIHN5c3RlbSBvdGhlciB0aGFuIGhhc2ggc2lnbmF0dXJlcywg c28gd2h5DQogbm90ICpqdXN0KiB1c2UgaGFzaCBzaWduYXR1cmVzPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gOCwgMjAyMCBh dCA4OjI2IEFNIE1pa2UgT3Vuc3dvcnRoICZsdDs8YSBocmVmPSJtYWlsdG86TWlrZS5PdW5zd29y dGhAZW50cnVzdGRhdGFjYXJkLmNvbSI+TWlrZS5PdW5zd29ydGhAZW50cnVzdGRhdGFjYXJkLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzAz MEEwIj5Fa3Igc2FpZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkluIHRoZSBm b3JtZXIgY2FzZSwgZXZlcnkgc2VydmVyIHdvdWxkIG5lZWQgdHdvIGNlcnRpZmljYXRlcyAob25l IGNvbXBvc2l0ZSBhbmQgb25lIGNsYXNzaWNhbCkgYW5kIHVzZSBzaWduYXR1cmVfYWxnb3JpdGht cyB0byBkaXN0aW5ndWlzaCB3aGljaCBvbmUgdG8gdXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzcwMzBBMCI+SSBhZ3JlZSB3aXRoIHlvdXIgY29uY2x1c2lvbiBhYm91dCBjb21wb3NpdGUg YnJlYWtpbmcgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzcwMzBBMCI+VGhhdCBzYWlkLCBJIGNhdXRpb24gdXMgYWdhaW5zdCB0aGlua2lu ZyBhYm91dCB0aGlzIHByb2JsZW0gb25seSBpbiB0ZXJtcyBvZiBhIHNpbmdsZSB1c2UtY2FzZSBv ciBwcm90b2NvbCAoVExTIGluIHRoaXMgY2FzZSkuJm5ic3A7IEkgd2FudCB0byBrZWVwIHRoaXMg ZGlzY3Vzc2lvbg0KIGNvbnNpZGVyaW5nIGNlcnRpZmljYXRlIHVzZS1jYXNlcyB0aGF0IGRvbuKA mXQgaGF2ZSBhbGdvcml0aG0gbmVnb3RpYXRpb24gbWVjaGFuaXNtcywgZm9yIGV4YW1wbGUgY29k ZS1zaWduaW5nLCBTL01JTUUsIFBLSSBzbWFydCBjYXJkcywgZmlsZSBlbmNyeXB0aW9uLCB3aGF0 ZXZlciB1c2VzIGNlcnRpZmljYXRlcyBpbiBhIHdheSB0aGF0IGlzbuKAmXQg4oCcb25saW5l4oCd LiZuYnNwOyBJIHdvdWxkIGxvdmUgdG8gc2VlIHRoZSBJRVRGIHByb3ZpZGUgYSBzb2x1dGlvbg0K IHRoYXQgYXBwbGllcyB0byBjZXJ0aWZpY2F0ZXMgYW5kIHNpZ25hdHVyZXMgaW4gZ2VuZXJhbCwg cmF0aGVyIHRoYW4gcHVudGluZyB0aGlzIHByb2JsZW0gdG8gZWFjaCBwcm90b2NvbCBkZXNpZ24g dGVhbSB0byBzb2x2ZSBpbmRlcGVuZGVudGx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhlIHByaW1hcnkgcmF0aW9uYWxlIGZvciBk b2luZyBQUSBhdXRoZW50aWNhdGlvbiBub3cgKG9yIGZvciB0aGF0PGJyPg0KbWF0dGVyIGNvbXBv c2l0ZSBhdXRoZW50aWNhdGlvbikgaXMgdG8gYmUgcHJlcGFyZWQgZm9yIHRoZSBkYXkgd2hlbiBR Qzxicj4NCmV4aXN0cyBhbmQgd2UgYXJlIHRoZXJlZm9yZSB1bmFibGUgdG8gcmVseSBvbiBjbGFz c2ljYWw8YnI+DQphbGdvcml0aG1zLiBIb3dldmVyLCBpdCdzIG5vdCB1c2VmdWwgdG8gYmUgcHJl cGFyZWQgaW4gdGhhdCBmYXNoaW9uPGJyPg0KdW5sZXNzIHRoZSBhbGdvcml0aG0gdGhhdCB5b3Ug YXJlIGRlcGxveWluZyBpcyB0aGUgb25lIHRoYXQgaXM8YnI+DQpldmVudHVhbGx5IHNlbGVjdGVk LCBiZWNhdXNlIG90aGVyd2lzZSB5b3UganVzdCBoYXZlIHRvIHN0YXJ0IG92ZXI8YnI+DQpvbmNl IHRoZSBzZWxlY3Rpb24gaXMgbWFkZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojNzAzMEEwIj5UaGlzIGNvbmNsdXNpb24g4oCTIHRoYXQgeW914oCZcmUg b25seSBnZXR0aW5nIHNlY3VyaXR5IHZhbHVlIG9uY2UgYSBQUSBleGlzdHMsIGFuZCBhbnkgYWxn IGltcGxlbWVudGF0aW9uIHdlIGNob3NlIHRvZGF5IHdpbGwgbGlrZWx5IGJlIG9ic29sZXRlIGJ5 IHRoZW4NCiAtLSBpcyBwcm9iYWJseSByaWdodCBmb3IgYnJvd3NlcnMsIGJ1dCB3aGF0IGFib3V0 IElvVCBkZXZpY2VzIHZhbGlkYXRpbmcgdGhlaXIgZmlybXdhcmUgc2lnbmF0dXJlIG9uIGJvb3Q/ IE9yIFBLSSBzbWFydGNhcmRzPyZuYnNwOyBPciBsZWdhbCBjb250cmFjdHMgc2lnbmVkIHVuZGVy IGVJREFTPyZuYnNwOyBUb2RheSB3ZSBhcmUgY3JlYXRpbmcgY2VydGlmaWNhdGVzIGFuZCBzaWdu ZWQgZGF0YSBvYmplY3RzIHRoYXQgd2lsbCBvdXRsaXZlIHRoZSBhZHZlbnQgb2YNCiBhIFFDLiZu YnNwOyBJIHRoaW5rIHRoYXQgYmx1cnMgY2xvc2VyIHRvIHRoZSDigJxyZXRyb3NwZWN0aXZlIGF0 dGFja+KAnSBzY2VuYXJpbyB0aGF0IHlvdSB1c2VkIGZvciBtb3RpdmF0aW5nIGNvbXBvc2l0ZSBr ZXkgZXhjaGFuZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+V2hp bGUgSeKAmW0gYXdhcmUgdGhhdCBJ4oCZbSB1c2luZyBtb3RpdmF0aW5nIGV4YW1wbGVzIGZyb20g b3V0c2lkZSB0aGUgSUVURiwgSSB0aGluayB3ZSBoYXZlIGFuIG9wcG9ydHVuaXR5IHRvIGRlZmlu ZSBhIHN0YW5kYXJkIHRoYXQgaXMgZ2VuZXJpYyBmb3IgYWxsDQogKG9yIGF0IGxlYXN0IG1vc3Qp IGNlcnRpZmljYXRlIHVzZS1jYXNlcy4mbmJzcDsgTGV04oCZcyBkbyB0aGUgZGViYXRlIGhlcmUg YWJvdXQgY2FycnlpbmcgbXVsdGlwbGUgc2lnbmF0dXJlcyBhbmQgdGhlIHNlbWFudGljcyBvZiB2 YWxpZGF0aW5nIGl0LCByYXRoZXIgdGhhbiBwdXNoaW5nIGl0IG91dCB0byBlYWNoIHByb3RvY29s IGRlc2lnbiB0ZWFtIHRvIGRlYmF0ZSBpbmRlcGVuZGVudGx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojNzAz MEEwIj4tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNzAzMEEwIj5NaWtlPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzcwMzBBMCI+IE91bnN3b3J0aA0KPGI+fDwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzAzMEEwIj5PZmZpY2U8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmdyYXkiPjogJiM0MzsxICg2MTMpIDI3MC0yODczPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gU2VjZGlzcGF0Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzpz ZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2VjZGlzcGF0Y2gt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29y bGE8YnI+DQo8Yj5TZW50OjwvYj4gSmFudWFyeSAyLCAyMDIwIDI6MTEgUE08YnI+DQo8Yj5Ubzo8 L2I+IENhcnJpY2sgQmFydGxlICZsdDs8YSBocmVmPSJtYWlsdG86Y2JhcnRsZTg5MUBpY2xvdWQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+Y2JhcnRsZTg5MUBpY2xvdWQuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IERyLiBQYWxhICZsdDs8YSBocmVmPSJtYWlsdG86bWFkd29sZkBvcGVuY2Eub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bWFkd29sZkBvcGVuY2Eub3JnPC9hPiZndDs7IFNhbHosIFJpY2gg Jmx0OzxhIGhyZWY9Im1haWx0bzpyc2FsekBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnNh bHpAYWthbWFpLmNvbTwvYT4mZ3Q7OyBJRVRGIFNlY0Rpc3BhdGNoICZsdDs8YSBocmVmPSJtYWls dG86c2VjZGlzcGF0Y2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZWNkaXNwYXRjaEBpZXRm Lm9yZzwvYT4mZ3Q7Ow0KIFN0ZXBoZW4gRmFycmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWUiIHRhcmdldD0iX2JsYW5rIj5zdGVwaGVuLmZhcnJlbGxAY3Mu dGNkLmllPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXVJlOiBbU2VjZGlz cGF0Y2hdIENsYXJpZmljYXRpb24gUXVlc3Rpb24gZm9yIHRoZSBDb21tZW50IGZyb20gRXJpYyBS ZXNjb3JsYSAoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj5XQVJOSU5HOjwvc3Bhbj48L2I+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBvdXRzaWRl IG9mIEVudHJ1c3QgRGF0YWNhcmQuPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+RE8g Tk9UIENMSUNLPC9zcGFuPjwvYj4gbGlua3Mgb3IgYXR0YWNobWVudHMgdW5sZXNzIHlvdSB0cnVz dCB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuPG86cD48L286cD48L3A+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKYW4gMiwg MjAyMCBhdCAxMToxOSBBTSBDYXJyaWNrIEJhcnRsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNiYXJ0 bGU4OTFAaWNsb3VkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNiYXJ0bGU4OTFAaWNsb3VkLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3Ig Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCAmcXVvdDtzdGFy dCBvdmVyJnF1b3Q7IG1lYW5zIGluIHRoaXMgY2FzZSBpcyBnZXQgdG8gdGhlIHBvaW50IHdoZXJl IHRoZXJlIGlzIGEgY3JpdGljYWwgbWFzcyBvZiBjbGllbnQgYW5kIHNlcnZlciBkZXBsb3ltZW50 LCBhIHByb2Nlc3Mgd2hpY2ggdGFrZXMgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JIHNlZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIG5vdCwgYXQgbGVhc3QgZm9yIFRM Uy4gVGhlIGNvbnNlbnN1cyBvZiBpbXBsZW1lbnRvcnMgc2VlbXMgdG8gYmUgdGhhdCBpdCdzIGJl dHRlciB0byBqdXN0IGNhc3QgY29tcG9zaXRlIGFsZ29yaXRobXMgYXMgaWYgdGhleSB3ZXJlIG5l dyBESCBncm91cHMsIHNvIHRoZXJlJ3Mgbm90IGEgaHVnZQ0KIGFtb3VudCBvZiBsZXZlcmFnZSBp biBhIGdlbmVyaWMgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgQ2xvdWRmbGFyZS1Hb29nbGUgaW1wbGVtZW50YXRp b24gZ2VuZXJhdGVkIHR3byBzZXBhcmF0ZSBzaGFyZWQgc2VjcmV0cy4gQWxzbyB0aGlzIGRyYWZ0 IHJlZmVyZW5jZXMgc2V2ZXJhbCBkaWZmZXJlbnQgJnF1b3Q7YWQgaG9jJnF1b3Q7IGFwcHJvYWNo ZXMgaW4gaW1wbGVtZW50YXRpb25zOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zdGViaWxhLXRscy1oeWJyaWQtZGVzaWduLTAxIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXN0ZWJpbGEtdGxzLWh5YnJpZC1k ZXNpZ24tMDE8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZWxsLCB5ZXMsIGJ1dCBvbiB0 aGUgd2lyZSBpdCdzIHBhY2thZ2VkIGFzIGEgc2luZ2xlIGdyb3VwIGFuZCBrZXkgc2hhcmUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YSBocmVmPSJodHRwczovL2Jsb2cuY2xvdWRmbGFyZS5jb20vdGhlLXRscy1wb3N0LXF1YW50dW0t ZXhwZXJpbWVudC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Jsb2cuY2xvdWRmbGFyZS5jb20v dGhlLXRscy1wb3N0LXF1YW50dW0tZXhwZXJpbWVudC88L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tRWtyPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xv ciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Q2FycmljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBKYW4gMiwgMjAyMCwgYXQgMTA6NTAgQU0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1h aWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5PbiBUaHUsIEphbiAyLCAyMDIwIGF0IDEwOjQ1IEFNIENhcnJpY2sgQmFydGxlICZs dDs8YSBocmVmPSJtYWlsdG86Y2JhcnRsZTg5MUBpY2xvdWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ Y2JhcnRsZTg5MUBpY2xvdWQuY29tPC9hPiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9y IHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aXQncyBub3QgdXNlZnVsIHRvIGJl IHByZXBhcmVkIGluIHRoYXQgZmFzaGlvbjxicj4NCnVubGVzcyB0aGUgYWxnb3JpdGhtIHRoYXQg eW91IGFyZSBkZXBsb3lpbmcgaXMgdGhlIG9uZSB0aGF0IGlzPGJyPg0KZXZlbnR1YWxseSBzZWxl Y3RlZCwgYmVjYXVzZSBvdGhlcndpc2UgeW91IGp1c3QgaGF2ZSB0byBzdGFydCBvdmVyPGJyPg0K b25jZSB0aGUgc2VsZWN0aW9uIGlzIG1hZGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SnVzdCB0byBi ZSBzcGVjaWZpYywgZG8geW91IG1lYW4sIGZvciBpbnN0YW5jZSwgYWxsIHRoZSBjZXJ0aWZpY2F0 ZXMgd2l0aCB0aGUgUFEgYWxnb3JpdGhtIHRoYXQgd2Fzbid0IGNob3NlbiB3b3VsZA0KIGhhdmUg dG8gYmUgcmV2b2tlZD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Qcm9iYWJseSBub3QuJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QXQgYSBoaWdoIGxldmVs LCB0aGVyZSBhcmUgdHdvIHBvc3NpYmxlIGRlc2lnbnM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MS4gQSBjZXJ0aWZpY2F0ZSB3aGljaCBoYXMg YSBjb21wb3NpdGUgc2lnbmF0dXJlIGluIHBsYWNlIG9mIHRoZSBjbGFzc2ljYWwgc2lnbmF0dXJl IGFuZCB0aHVzIGNhbm5vdCBiZSB2YWxpZGF0ZWQNCiBieSBvbGQgY2xpZW50cy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4yLiBBIGNlcnRpZmljYXRlIHdoaWNoIGhhcyBhIFBRIHNpZ25hdHVyZSBz b21laG93IGF0dGFjaGVkIGluIGEgd2F5IHRoYXQgaXQgbGVhdmVzIHRoZSBjbGFzc2ljYWwgc2ln bmF0dXJlIHZhbGlkDQogKGFzIGluIGFuIGV4dGVuc2lvbikuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIGZvcm1lciBjYXNlLCBldmVy eSBzZXJ2ZXIgd291bGQgbmVlZCB0d28gY2VydGlmaWNhdGVzIChvbmUgY29tcG9zaXRlIGFuZCBv bmUgY2xhc3NpY2FsKSBhbmQgdXNlIHNpZ25hdHVyZV9hbGdvcml0aG1zDQogdG8gZGlzdGluZ3Vp c2ggd2hpY2ggb25lIHRvIHVzZS4gT25jZSBjbGllbnRzIHN0b3BwZWQgbGlraW5nIHRoZSBvbGQg UFEgYWxnb3JpdGhtLCB0aGVuIHRob3NlIGNvbXBvc2l0ZSBjZXJ0aWZpY2F0ZXMgd291bGQgYmVj b21lIGlycmVsZXZhbnQgYW5kIGp1c3QgYmUgdW51c2VkLiBJbiB0aGUgbGF0dGVyIGNhc2UsIHRo ZSBjZXJ0aWZpY2F0ZXMgd291bGQgY29udGludWUgdG8gYmUgdmFsaWQgYW5kIHRoZSBjbGllbnQg Y291bGQganVzdCBpZ25vcmUNCiB0aGUgUFEgcGFydCBvZiB0aGUgc2lnbmF0dXJlLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgJnF1b3Q7 c3RhcnQgb3ZlciZxdW90OyBtZWFucyBpbiB0aGlzIGNhc2UgaXMgZ2V0IHRvIHRoZSBwb2ludCB3 aGVyZSB0aGVyZSBpcyBhIGNyaXRpY2FsIG1hc3Mgb2YgY2xpZW50IGFuZCBzZXJ2ZXIgZGVwbG95 bWVudCwNCiBhIHByb2Nlc3Mgd2hpY2ggdGFrZXMgdGltZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xv ciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPnRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgZG9pbmcgY29tcG9zaXRlIGtl eSBleGNoYW5nZSBub3cgaXMgdG88YnI+DQpkZWZlbmQgYWdhaW5zdCByZXRyb3NwZWN0aXZlIGF0 dGFja3MgaW4gY2FzZSBhIHF1YW50dW0gY29tcHV0ZXIgZXhpc3RzPGJyPg0KaW4gdGhlIGZ1dHVy ZS4gSW4gdGhpcyBzZXR0aW5nLCBpdCBpc24ndCBjcml0aWNhbGx5IGltcG9ydGFudCB0byBoYXZl PGJyPg0KdGhlIFBRIGFsZ29yaXRobSBiZSB0aGUgb25lIHdlIGV2ZW50dWFsbHkgbGFuZCBvbiwg YmVjYXVzZSBlYWNoPGJyPg0KY29ubmVjdGlvbiBpcyBzZXBhcmF0ZWx5IG5lZ290aWF0ZWQgYW5k IGFzIGxvbmcgYXMgdGhlIFBRIGFsZ29yaXRobTxicj4NCmhhcyBzb21lIHNlY3VyaXR5LCB5b3Un cmUgZ2V0dGluZyBiZW5lZ2l0LC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J biB0aGF0IGNhc2UsIHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gdGFrZSB0aGUgbmV4dCBzdGVwIHdp dGggZHJhZnRpbmcgYW4gaW50ZW5kZWQgc3RhbmRhcmQgZm9yIGNvbXBvc2l0ZSBrZXkgZXhjaGFu Z2VzDQogKHRoYXQgaXMgUFEgYWxnb3JpdGhtLWFnbm9zdGljKT8gSWYgbm90LCB3aHkgbm90Pzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayBub3QsIGF0IGxlYXN0IGZvciBUTFMuIFRoZSBjb25z ZW5zdXMgb2YgaW1wbGVtZW50b3JzIHNlZW1zIHRvIGJlIHRoYXQgaXQncyBiZXR0ZXIgdG8ganVz dCBjYXN0IGNvbXBvc2l0ZQ0KIGFsZ29yaXRobXMgYXMgaWYgdGhleSB3ZXJlIG5ldyBESCBncm91 cHMsIHNvIHRoZXJlJ3Mgbm90IGEgaHVnZSBhbW91bnQgb2YgbGV2ZXJhZ2UgaW4gYSBnZW5lcmlj IG1lY2hhbmlzbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4tRWtyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRj b2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2Fycmljazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+T24gRGVjIDI1LCAyMDE5LCBhdCA1OjU3IFBNLCBFcmljIFJlc2Nvcmxh ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0 Zm0uY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gTW9uLCBEZWMgMjMsIDIwMTkgYXQgODozOCBQTSBD YXJyaWNrIEJhcnRsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNiYXJ0bGU4OTFAaWNsb3VkLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmNiYXJ0bGU4OTFAaWNsb3VkLmNvbTwvYT4mZ3Q7DQogd3JvdGU6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBIb3cgY2FuIGl0IGJlIHRydWUgdGhhdCBpdCdzIHRv byBlYXJseSB0byBzdGFydCBkZXZlbG9waW5nIGEgcHJvdG9jb2w8YnI+DQomZ3Q7IGZvciBjb21w b3NpdGUga2V5cyBhbmQgc2lnbmF0dXJlcyBmb3IgV2ViIFBLSSB3aGVuIENsb3VkZmxhcmUgYW5k PGJyPg0KJmd0OyBHb29nbGUgaGF2ZSBhbHJlYWR5IGZpbmlzaGVkIGEgcm91bmQgb2YgZXhwZXJp bWVudHMgd2l0aCBjb21wb3NpdGUga2V5PGJyPg0KJmd0OyBleGNoYW5nZXM/IE1heWJlIEknbSBy ZWFkaW5nIHRvbyBtdWNoIGludG8gaXQsIGJ1dCB0aGUgZXhpc3RlbmNlIG9mPGJyPg0KJmd0OyB0 aG9zZSBleHBlcmltZW50cyBzdWdnZXN0ZWQgdG8gbWUgdGhhdCB0aGUgbmVlZCBmb3IgY29tcG9z aXRlL2NvbXBvc2l0ZTxicj4NCiZndDsgaW1wbGVtZW50YXRpb25zIHdhcyBpbW1pbmVudC4gKEkg dW5kZXJzdGFuZCB0aGF0IHRoZSBkcmFmdCBpbiBxdWVzdGlvbjxicj4NCiZndDsgY29uY2VybnMg c2lnbmF0dXJlcywgbm90IGtleSBleGNoYW5nZXMsIGJ1dCBhcHBhcmVudGx5IHRoZXJlIGlzbid0 PGJyPg0KJmd0OyBldmVuIGEgZHJhZnQgZm9yIHRoZSBsYXR0ZXIgeWV0Lik8YnI+DQo8YnI+DQpJ U1RNIHRoYXQgdGhlc2UgY2FzZXMgYXJlIHByZXR0eSBkaWZmZXJlbnQsIGluIGEgbnVtYmVyIG9m IHJlc3BlY3RzLjxicj4NCjxicj4NCkZpcnN0LCB0aGUgcHJpbWFyeSByYXRpb25hbGUgZm9yIGRv aW5nIGNvbXBvc2l0ZSBrZXkgZXhjaGFuZ2Ugbm93IGlzIHRvPGJyPg0KZGVmZW5kIGFnYWluc3Qg cmV0cm9zcGVjdGl2ZSBhdHRhY2tzIGluIGNhc2UgYSBxdWFudHVtIGNvbXB1dGVyIGV4aXN0czxi cj4NCmluIHRoZSBmdXR1cmUuIEluIHRoaXMgc2V0dGluZywgaXQgaXNuJ3QgY3JpdGljYWxseSBp bXBvcnRhbnQgdG8gaGF2ZTxicj4NCnRoZSBQUSBhbGdvcml0aG0gYmUgdGhlIG9uZSB3ZSBldmVu dHVhbGx5IGxhbmQgb24sIGJlY2F1c2UgZWFjaDxicj4NCmNvbm5lY3Rpb24gaXMgc2VwYXJhdGVs eSBuZWdvdGlhdGVkIGFuZCBhcyBsb25nIGFzIHRoZSBQUSBhbGdvcml0aG08YnI+DQpoYXMgc29t ZSBzZWN1cml0eSwgeW91J3JlIGdldHRpbmcgYmVuZWdpdCwuPGJyPg0KPGJyPg0KVGhlIHByaW1h cnkgcmF0aW9uYWxlIGZvciBkb2luZyBQUSBhdXRoZW50aWNhdGlvbiBub3cgKG9yIGZvciB0aGF0 PGJyPg0KbWF0dGVyIGNvbXBvc2l0ZSBhdXRoZW50aWNhdGlvbikgaXMgdG8gYmUgcHJlcGFyZWQg Zm9yIHRoZSBkYXkgd2hlbiBRQzxicj4NCmV4aXN0cyBhbmQgd2UgYXJlIHRoZXJlZm9yZSB1bmFi bGUgdG8gcmVseSBvbiBjbGFzc2ljYWw8YnI+DQphbGdvcml0aG1zLiBIb3dldmVyLCBpdCdzIG5v dCB1c2VmdWwgdG8gYmUgcHJlcGFyZWQgaW4gdGhhdCBmYXNoaW9uPGJyPg0KdW5sZXNzIHRoZSBh bGdvcml0aG0gdGhhdCB5b3UgYXJlIGRlcGxveWluZyBpcyB0aGUgb25lIHRoYXQgaXM8YnI+DQpl dmVudHVhbGx5IHNlbGVjdGVkLCBiZWNhdXNlIG90aGVyd2lzZSB5b3UganVzdCBoYXZlIHRvIHN0 YXJ0IG92ZXI8YnI+DQpvbmNlIHRoZSBzZWxlY3Rpb24gaXMgbWFkZS48YnI+DQo8YnI+DQpNb3Jl b3ZlciwgaW4gb3JkZXIgdG8gYmUgdHJ1bHkgcHJlcGFyZWQsIHdoYXQgeW91IG5lZWQgaXNuJ3Q8 YnI+DQpwcmluY2lwYWxseSByZWx5aW5nIHBhcnR5IGRlcGxveW1lbnQsIGJ1dCByYXRoZXIgYXV0 aGVudGljYXRpbmcgcGFydHk8YnI+DQooaW4gdGhlIGNhc2Ugb2YgdGhlIFdlYlBLSSwgc2VydmVy LXNpZGUpIGRlcGxveW1lbnQuIFRoZSByZWFzb24gZm9yPGJyPg0KdGhpcyBpcyB0aGF0IGluIHRo ZSB3b3JsZCB3aGVyZSBhIFFDIGV4aXN0cywgeW91IGRvbid0IGhhdmUgcHJvdGVjdGlvbjxicj4N CnVudGlsIHRoZSByZWx5aW5nIHBhcnR5IHJlZnVzZXMgdG8gYWNjZXB0IHRoZSBjbGFzc2ljYWwg Y3JlZGVudGlhbDxicj4NClswXSwgYW5kIGF0IHByZXNlbnQsIGFueSBjbGllbnQgd2hpY2ggZG9l cyBzbyB3aWxsIGVmZmVjdGl2ZWx5IGJlPGJyPg0KdW5hYmxlIHRvIGNvbW11bmljYXRlLiBBbmQg aW4gb3JkZXIgdG8gbWFrZSB0aGF0IGhhcHBlbiwgcmVseWluZzxicj4NCnBhcnRpZXMgd2lsbCBo YXZlIHRvIHJlcXVpcmUgYSBwb3N0LXF1YW50dW0gYWxnb3JpdGhtIChtb3N0IGxpa2VseSBhczxi cj4NCmEgY29tcG9zaXRlKSBhbmQgdGhhdCdzIHNvbWV0aGluZyBJIGRvbid0IGV4cGVjdCB0aGVt IHRvIGJlIHdpbGxpbmcgdG8gZG88YnI+DQp1bnRpbCB0aGVyZSdzIHdpZGVzcHJlYWQgYWdyZWVt ZW50IG9uIHdoYXQgdGhhdCBhbGdvcml0aG0gc2hvdWxkIGJlLjxicj4NCjxicj4NCjxicj4NCiZn dDsgSWYgbm90IG5vdywgd2hlbj8gQWZ0ZXIgTklTVCBjcm93bnMgYSB3aW5uZXI/IEkgZG9uJ3Qg c2VlIHdoeSBpdCdzPGJyPg0KJmd0OyBuZWNlc3NhcnkgdG8gd2FpdCB0aGF0IGxvbmcgZ2l2ZW4g dGhhdCB0aGUgcHJvcG9zZWQgc29sdXRpb25zIGFyZTxicj4NCiZndDsgYWxnb3JpdGhtLWluZGVw ZW5kZW50LiBBbmQgc2luY2UgdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIHRha2VzIGE8YnI+ DQomZ3Q7IHdoaWxlLCB3b24ndCB3YWl0aW5nIHVudGlsIHRoZW4gbWVhbiB0aGF0IHRoZXJlIHdv bid0IGJlIGEgc3RhbmRhcmQ8YnI+DQomZ3Q7IHVudGlsIGFmdGVyIGl0J3MgbmVlZGVkPzxicj4N Cjxicj4NCk5vLCBpIGRvbid0IHRoaW5rIHNvLjxicj4NCjxicj4NCkZvciB0aGUgcmVhc29ucyBh Ym92ZSwgSVNUTSB0aGF0IHJlYWwgZGVwbG95bWVudCB3aWxsIGhhdmUgdG8gd2FpdDxicj4NCnVu dGlsIHdlIGhhdmUgYSBzZWxlY3RlZCBhbGdvcml0aG0uIE9uZSBjb3VsZCwgYXMgeW91IHN1Z2dl c3QsIGRlcGxveTxicj4NCnNvbWUgc29ydCBvZiBtdWx0aS1hbGdvcml0aG0gY29udGFpbmVyLCBi dXQgSU1PIHdlIHdpbGwgYmUgZmFyIGJldHRlcjxicj4NCm9mZiBqdXN0IGRlcGxveWluZyBuZXcg Y29tcG9zaXRlIGFsZ29yaXRobXMgYXMgaWYgdGhlIHdlcmUgc2luZ2xlPGJyPg0KbmV3IGFsZ29y aXRobXMsIGluIHRoZSBzYW1lIHdheSBhcyB3ZSBoYXZlIGRvbmUgZm9yIGtleSBlc3RhYmxpc2ht ZW50Ljxicj4NCjxicj4NCkZvciB0aGlzIHJlYXNvbiwgSSB0aGluayB3ZSBvdWdodCB0byB3YWl0 IHVudGlsIHRoZXJlIGlzIGEgY29uc2Vuc3VzPGJyPg0KUFEgc2lnbmF0dXJlIGFsZ29yaXRobSwg YXQgbGVhc3QgZm9yIHRoZSBXZWJQS0kuPGJyPg0KPGJyPg0KLUVrcjxicj4NCjxicj4NClswXSBU aGlzIGlzIHdoeSB0aGlzIGtpbmQgb2YgY29tcG9zaXRlIGlzbid0IGhlbHBmdWwgaW4gdGhlIHdv cmxkPGJyPg0Kd2hlcmUgYSBzZWNyZXQgUUMgZXhpc3RzIG5vdC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3Vy cmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KU2VjZGlzcGF0Y2ggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNlY2Rpc3BhdGNoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+U2VjZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2g8L2E+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR11MB3883C9BD22D63B64B59928EC9B3E0DM6PR11MB3883namp_-- From nobody Thu Jan 9 05:20:49 2020 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45E12001E; Thu, 9 Jan 2020 05:20:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, secdispatch@ietf.org, francesca.palombini@ericsson.com, secdispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157857604861.11833.8431133332594117360.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2020 05:20:48 -0800 Archived-At: Subject: [Secdispatch] secdispatch - New Meeting Session Request for IETF 107 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:20:49 -0000 A new meeting session request has just been submitted by Francesca Palombini, a Chair of the secdispatch working group. --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: saag dispatch ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mile mls oauth rats sacm secevent suit teep tls tokbind trans cbor core gendispatch Technology Overlap: httpbis People who must be present: Kathleen Moriarty Roman Danyliw Richard Barnes Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with any Security related BoF. Please schedule for a session of at least 2h. --------------------------------------------------------- From nobody Thu Jan 16 11:13:18 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998631208CD for ; Thu, 16 Jan 2020 11:13:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le_cyUnIsuY2 for ; Thu, 16 Jan 2020 11:13:15 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6878B1209A6 for ; Thu, 16 Jan 2020 11:13:15 -0800 (PST) IronPort-SDR: cyLB24a1R8+DousqAxBkqs5jj8BFuCUHcyPlFQvZLTAmOTK3H5gSVfVuQqltrbVnvXZW/O2Yho jByU++FRUKIw== X-IronPort-AV: E=Sophos;i="5.70,327,1574143200"; d="scan'208";a="7698755" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 16 Jan 2020 13:13:14 -0600 Received: from PMSPEX04.corporate.datacard.com (192.168.211.51) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jan 2020 13:13:14 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (172.28.1.8) by PMSPEX04.corporate.datacard.com (192.168.211.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 16 Jan 2020 13:13:14 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RPz/h88pUhE0SOnAawSZj+1J+bgaX+99MsGF8yb07zdi1uFVkCNd2axkrGorwFF4xyGU9KAPf0h906c+cWg4NRxUSC/2ULtS9xf56WjBq7m5X7M+pVpMx9vxW0W/z+QM9UhnLBUFH/h6y5I4LskQWSdvL2upD9TRUQlSrZCiutmuA67zdH2a9dS551ybXg9y5EkVCs3qJ9p85v6xfxl85UvZzU7b4SajsYs6IfOcd1iwoEYEoqM6reke4N8aWrjTz7jESB8Mgj3riQkVQLFnmWYVe6zLT6+nntHTqSukBS05RwZbJgkSdN93Y2i2YT6PJUL3PzlJV23T8Ixn8vL3Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Me5+2oXO7Z0UCxzGy/2jmO3fp1PVve7i23j049OAb0=; b=XNRZSjwoLpbLxRjSnuBeDcH9HJ3Cv6AdMGuk8Sd3m2v32VVha07ERW+1o14nVaA9kLrHJmr2ZCXFbLIs9Dm0aFS72y/9VomskKCK/GiA/aIznLUwNaDQtu9yvSnNlEoPydRkswwLIFzMxnMPj1GyvccDuWVlgZ4oJ85GPtmOy3zmTEipBZulRRJKljJ6kKVbfrG/mTbcPDKNl84xwDaNuEHvuJ4xyigotVa4rfUiACm9BEjQDjwK59cJMHAG3xGx/UbJMvVpJQ4vNRlac97jfGljmvBvgk4vDpgZeJKsQbnTQBmkNaAewBgpvxjmT1OmS04NKDQc0ik3HuCpl8E7ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Me5+2oXO7Z0UCxzGy/2jmO3fp1PVve7i23j049OAb0=; b=yKEeLMG/GTcMopoOGu1zr1xfI0dI7rE+Wkq1cP6wa6scKbnn8zZfGaK2kfteTIOPOzMCffz4ti9Q2W8I4he9Y+Hw1XSPzvtGqg7yqLcWvwWSLnHpvlcb2YWIIu6vFeshhwhb+igYQ+EgfvgdYUU/rXFWxIYTTJ03sikXeVAUhtU= Received: from DM6PR11MB3883.namprd11.prod.outlook.com (10.255.61.32) by DM6PR11MB4345.namprd11.prod.outlook.com (52.132.251.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Thu, 16 Jan 2020 19:13:13 +0000 Received: from DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392]) by DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392%6]) with mapi id 15.20.2623.018; Thu, 16 Jan 2020 19:13:13 +0000 From: Mike Ounsworth To: IETF SecDispatch Thread-Topic: Can Composite sigs move back to LAMPS? Thread-Index: AdXMlh5Ba3U4rdZGTG6zfD9kbyUHDg== Date: Thu, 16 Jan 2020 19:13:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [204.124.81.102] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb800077-080b-4be7-7d0e-08d79ab821ff x-ms-traffictypediagnostic: DM6PR11MB4345: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(366004)(39860400002)(376002)(396003)(199004)(189003)(478600001)(52536014)(6916009)(71200400001)(2906002)(66556008)(33656002)(5660300002)(86362001)(66946007)(186003)(66476007)(26005)(66446008)(81156014)(81166006)(6506007)(55016002)(8676002)(316002)(8936002)(76116006)(64756008)(7696005)(9686003)(4744005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB4345; H:DM6PR11MB3883.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 02ITiUIxNTq+EEbtayKWJTEvuB/eutbw0RfxZxe7lEFFeVabTs0UP1xHYBB8TAj0cPJVFVCAUjYq46DOezGx0huHkC4f3k3VyIagQiQBg3KKa15FDA7OKAHv/G8IWNFyE63GbkApyf2j4ypsOKGB7rLVNNM6IQOm7nge4n6KqZyMeR9zHc4sWwdmYNAz0NYvD4Be5y3FsR6yx1dTUT83n1HOOiPVRSaaypFYkTZRChIn3y201RZK27DQecLIS2Un72vf2U4HXgIxFw7Pn+SjXZIMz3xSmkqbZIfYTNKWTqKAf4tSpGKE/y1zDmoKbJzkrq4gN82F6Ks1pNoB+1GmlgNAibiqxCpjoFW5eDhkr/UjbvUEmM+UND0AHIuBVJbYk3LyAhJMCXkHmH86gRUXRElSxLb2Px4JeXJDG61iUrnkqlKGHNit3UjoyjjkbEpx x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eb800077-080b-4be7-7d0e-08d79ab821ff X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2020 19:13:13.0486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1LjBACwL74mAbFHKgWHo6A6cRy243SSqYPYsnsXjh7k5l2mySIqx2i7QFMLdfFMrHFBY8Fl733nnD/7tjNWG1UT/RCOxxRCrJeOG07fVAv3ulN1g/1Gmc20cIpY/yQQd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4345 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 19:13:17 -0000 Following up on in-room discussions at 106, and the ensuing list discussion= s, I'd like to ask for confirmation of the following points: 1. There is enough interest in an obvious-and-straightforward implementatio= n of composite signatures to continue working on it? 1a. The current draft for this is draft-ounsworth-pq-composite-sigs-02 2. SecDispatch is assigning this back to LAMPS? 2a. The current draft might not be the most obvious-and-straightforward = implementation; we're willing to simplify until it's in-scope for LAMPS. --- Mike Ounsworth Software Security Architect, Entrust Datacard From nobody Thu Jan 16 11:28:04 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A3C1208FF for ; Thu, 16 Jan 2020 11:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OGI2tU7pgY5H for ; Thu, 16 Jan 2020 11:27:59 -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 EF7521208FB for ; Thu, 16 Jan 2020 11:27:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8AA62BE20; Thu, 16 Jan 2020 19:27:56 +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 PkTsywsvowLy; Thu, 16 Jan 2020 19:27:54 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B597EBDCF; Thu, 16 Jan 2020 19:27:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579202874; bh=VMIpxcs5pCQQp95tblLuwmZqwWA3/evjVqbuF1ldPmA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UUxRnFvA7FQLe77kNKj4vpqnfC9Db9YeFPH8Fva0zbvM3sq/FpPwz33O6FjygaE84 m4dhgyXDSzz6rPIhsuIih54uy2sJdg69LXgOF51kzGfeEW8w+yvc/w8og+gPkE+J9g V7Jgn4Oig7n8fHPEEVB+FY9dOlK4Vv3yqSaKHy3M= To: Mike Ounsworth , IETF SecDispatch References: From: Stephen Farrell 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: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> Date: Thu, 16 Jan 2020 19:27:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YuTPXPVyurPrDwvTDIGsBecgqICzpSIh8" Archived-At: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 19:28:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YuTPXPVyurPrDwvTDIGsBecgqICzpSIh8 Content-Type: multipart/mixed; boundary="ozQVm18F2D7ebsxzOWthZPhMuVv4NkueJ"; protected-headers="v1" From: Stephen Farrell To: Mike Ounsworth , IETF SecDispatch Message-ID: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? References: In-Reply-To: --ozQVm18F2D7ebsxzOWthZPhMuVv4NkueJ Content-Type: multipart/mixed; boundary="------------523E26A0009A6874A99CD969" Content-Language: en-US This is a multi-part message in MIME format. --------------523E26A0009A6874A99CD969 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I'm guessing it'll be no surprise that I reckon that we ought not adopt either piece of work at this time (sorry for being so predictablel;-) I continue to think waiting 'till we know more is wiser. I'd also note that CVE-2020-0601 may (when full details emerge) provide very direct evidence that standardising cryptographic parameter representations ahead of real understanding of the algorithms and their implementations and real uses can be a bad plan with implications that only hit decades later. Even if it turns out that (some years later) RFC5280 got it right in saying "don't do that", I'd argue earlier ASN.1 modules (whether from IETF, ITU-T, ANSI or whomever) got it wrong in ever providing a way to encode custom curve parameters. Regards, S. On 16/01/2020 19:13, Mike Ounsworth wrote: > Following up on in-room discussions at 106, and the ensuing list > discussions, I'd like to ask for confirmation of the following > points: >=20 > 1. There is enough interest in an obvious-and-straightforward > implementation of composite signatures to continue working on it? 1a. > The current draft for this is draft-ounsworth-pq-composite-sigs-02 >=20 > 2. SecDispatch is assigning this back to LAMPS? 2a. The current draft > might not be the most obvious-and-straightforward implementation; > we're willing to simplify until it's in-scope for LAMPS. >=20 > --- Mike Ounsworth Software Security Architect, Entrust Datacard >=20 > _______________________________________________ Secdispatch mailing > list Secdispatch@ietf.org=20 > https://www.ietf.org/mailman/listinfo/secdispatch >=20 --------------523E26A0009A6874A99CD969 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------523E26A0009A6874A99CD969-- --ozQVm18F2D7ebsxzOWthZPhMuVv4NkueJ-- --YuTPXPVyurPrDwvTDIGsBecgqICzpSIh8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4guToACgkQWrL68XsX K+rl+w//ePUg6SSA9gTGMXyFLpeqOMlPRqFtXXZod7AqM/VY+S9wNgxtUBAZu3LH KgjANFMRI8bQIwK2FEivfJlOomouyzj9C+a0m52smdXpwFpsiNhMMnwxWENpcJkW jr1ifrofq5UACmUOr305GSE1ekSFadD4Kbrwf9+Z6cHV1PtHYo95do4Ap/XaYfym i33kyaIbojYI0vctn5ffh7B/paPB+jubu4Ez07NZruh0u4Qe98wgyB28LX7RHy9M 4w25Tlcx1XNlQcjpgLGFLPgc8YFhWuJr1PmmSpRNqmWAyBf0MP+qW7dcKPBQMlT8 UCxp6ikMzTPEOZCaDQ/D8EO2ZRnw4/brsB3nFBva1EcFOYctb+geVr9tzL1lTvrT z7DfFP9LYBYCuhC66FrTIQ46xJMHTImWvXnXYEvD4uuPAiAEkmbVMFnlO2jKTrpv 4ghLZvsx8t6HCu/WxHYovU4qJHlDN3KmWzyeMRueuByivIyTBaAQ1PwxuLuLMyE4 b/CDtYHigXMvPE1lAfhSayfne/WUcl7moorX3zTHS6bl+DC1FfKFVf+acsUEJChJ PyC3/JGHwMbAuJj049HGdMtq1YMSCsgXYrPG1zgw7l2kWYa+nyrWSHSL4zjehz+U hvoXgSU+gRL/0FaF+/+iX8Kpe6IXhIgPtvQOUavSXZw9Jk9Q/aI= =r2GQ -----END PGP SIGNATURE----- --YuTPXPVyurPrDwvTDIGsBecgqICzpSIh8-- From nobody Thu Jan 16 13:21:39 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93783120026 for ; Thu, 16 Jan 2020 13:21:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pqshield-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ895iBTuJVf for ; Thu, 16 Jan 2020 13:21:33 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 EB68312004A for ; Thu, 16 Jan 2020 13:21:32 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id p2so9782691qvo.10 for ; Thu, 16 Jan 2020 13:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fKDAuzyhKxqTHXJJ2CC0m4LJfvxFbY8FU2dHwK4d+kU=; b=x1/ccfJU/o+PQQgGBSFHcSc3nfKcj7gaDEfwKDUdUkhKjSlDOHdl+iMqLT0XhQAJKA RHv1YVEQJLJL3ib/7WHF08yuy+pgH9W9AWVloT6URF3rBTi6H9RgOeZVfjFDligoFqdo T+9u1JmTYcTZ9828s1AyOO5Zn49sZUeklEucNQy0ZYT1fKxEcTWSjeYjui4i9DjZBOUv K7Pjogw30atmw5NHkTpLT7TV5T5ztZH1yqHT6SYzZjbqLqkB96+TydxP8Akru8oi5Pws gM/vGeNdwqgld6yppQ8sH001HOyqS9Uc5jrmeqUZlgRPspgIOQeT0aoJZMhnW/DomS70 hV5A== 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=fKDAuzyhKxqTHXJJ2CC0m4LJfvxFbY8FU2dHwK4d+kU=; b=WTbaAl5Nf91P/b6J0PLoOj6juCNpNyNGg39W7pyUoS8W0coOFV8O3Kk7pb7uVVUlWp BnE7O6yQYKS+jQWfMk4iOMdlJQyxsZUVLIQVHMf5WOmWref0lerKXft0Z1wPbQUA7UPz 8eb5qoQJd0pBJO8OM8JEJ7Ep45+ayYGzR0ZjD+WPTcq21lrM7a9AnQrzcYQDMwAPwLOp zpncx0rd4qpXTUCw6lS2HEDJ+tTxUXGeqQXN9Tf8amyb+uvORG7s6A2l6Foe8CkUkK6U 83rto9UJp1F9GRoR0Re7PCwuuCtr/sPrycaT7dJEs4lS4b1z9pSVBa3Hvcmj+ywfIkLB Cxmw== X-Gm-Message-State: APjAAAWKLGVZla1tqngUh2c6uUipSAMND47pI3d6x6eahevxQRm1Xcl0 zxoFAqJhHWgUN7sCPnH8yJ91lH3KnA1fSUzI1TILXexzjmI= X-Google-Smtp-Source: APXvYqyaScsshZGD+6+TwFJaj7wCsBCPiaO2e30GLpPlikpgLgxVYHhsORVtkJFHk1uGRVXyiZLVxfhyY6Wo5I1tc5o= X-Received: by 2002:a05:6214:14b3:: with SMTP id bo19mr4619082qvb.93.1579209692012; Thu, 16 Jan 2020 13:21:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Markku-Juhani O. Saarinen" Date: Thu, 16 Jan 2020 21:21:21 +0000 Message-ID: To: Mike Ounsworth Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000b7f88e059c4868c1" Archived-At: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 21:21:37 -0000 --000000000000b7f88e059c4868c1 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 16, 2020 at 7:13 PM Mike Ounsworth < Mike.Ounsworth@entrustdatacard.com> wrote: > Following up on in-room discussions at 106, and the ensuing list > discussions, I'd like to ask for confirmation of the following points: > > 1. There is enough interest in an obvious-and-straightforward > implementation of composite signatures to continue working on it? > 1a. The current draft for this is draft-ounsworth-pq-composite-sigs-02 > I'd certainly like this to proceed as it the only document of this type that is currently alive in IETF (as far as I know). As everyone knows, the NIST PQC process will soon be in its final third-round stretch and we're not the only vendor who is already quite familiar with the various proposals, has implemented them, and are in the process of making them commercially available in cooperation with PKI vendors. We don't want to end up in a nightmare scenario where each vendor pushing their own kind of dual/hybrid/composite/twin/double/mixed signature solution of highly variable design quality. In some ways IETF is perhaps behind the curve here as FIPS certification guidelines are being created for exactly the types of technologies that "draft-ounsworth-pq-composite-sigs-02" discusses. See e.g. https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs#xisl "In particular, a hybrid mode for signatures consists of two signatures. The mode is valid if and only if both signatures are valid." Hence the need for standardization of composite signatures. Stephen Farrell referred to CVE-2020-0601 -- I don't see how composite signatures is related to specific parameter representations. That has not been proposed, apart from OID identifiers for a type of composite signature. The composite can even be made up of ECC and RSA signatures. It is just an abstraction intended to help with the transition to the next set of standards, which is very much happening as it has been on e.g. the USG roadmap at least since the CNSA announcement in 2015. > 2. SecDispatch is assigning this back to LAMPS? > 2a. The current draft might not be the most obvious-and-straightforward > implementation; we're willing to simplify until it's in-scope for LAMPS. > This bouncing back and forth seems symptomatic of IETF. Those of use who are working on this technology will just have to "follow the specification around" if that happens. Anyway let's keep working on it. I'd be even ready to help push it through as "informational" on the strength of having interoperable industry implementations. Currently the level of detail is not sufficient for that, but we should be able to iterate enough detail in there if we do a little bit of engineering interop. As to what is the most appropriate forum for that, I'm open to suggestions. Cheers, - markku Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. --000000000000b7f88e059c4868c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 16, 2020 at 7:13 PM Mike= Ounsworth <Mike.O= unsworth@entrustdatacard.com> wrote:
Following up o= n in-room discussions at 106, and the ensuing list discussions, I'd lik= e to ask for confirmation of the following points:

1. There is enough interest in an obvious-and-straightforward implementatio= n of composite signatures to continue working on it?
=C2=A0 =C2=A01a. The current draft for this is draft-ounsworth-pq-composite= -sigs-02

I'd certainly like th= is to proceed as it the only document of this type that is currently alive = in IETF (as far as I know).=C2=A0

As everyone know= s, the NIST PQC process will soon be in its final third-round stretch and w= e're not the only vendor who is already quite familiar with the various= proposals, has implemented them, and are in the process of making them com= mercially available in cooperation with PKI vendors. We don't want to e= nd up in a nightmare scenario where each vendor pushing their own kind of d= ual/hybrid/composite/twin/double/mixed signature solution of highly variabl= e design quality.

In some ways IETF is perhaps beh= ind the curve here as FIPS certification guidelines are being created for e= xactly the types of technologies that "draft-ounsworth-pq-composite-si= gs-02" discusses. See e.g.=C2=A0https://csrc.nist.gov/Projects/Po= st-Quantum-Cryptography/faqs#xisl=C2=A0"In particular, a hybrid mo= de for signatures consists of two signatures. The mode is valid if and only= if both signatures are valid." Hence the need for standardization of = composite signatures.
=C2=A0
Stephe= n Farrell referred to=C2=A0CVE-2020-0601 --=C2=A0 I don't=C2=A0see how = composite signatures is related to specific parameter representations.=C2= =A0That has not been proposed, apart from OID identifiers for a type of com= posite signature. The composite can even be made up of ECC and RSA signatur= es. It is just an abstraction intended to help with the transition to the n= ext set of standards, which is very much happening as it has been on e.g. t= he USG roadmap at least since the CNSA announcement in 2015.
=C2=A0
2. SecDispatch is assigning this back to LAMPS?
=C2=A0 =C2=A02a. The current draft might not be the most obvious-and-straig= htforward implementation; we're willing to simplify until it's in-s= cope for LAMPS.
=C2=A0
This bouncing b= ack and forth seems symptomatic of IETF. Those of use who are working on th= is technology will just have to "follow the specification around"= if that happens.

Anyway let's keep working on= it. I'd be even ready to help push it through as "informational&q= uot; on the strength of having interoperable industry implementations. Curr= ently the level of detail is not sufficient for that, but we should be able= to iterate enough detail in there if we do a little bit of engineering int= erop. As to what is the most appropriate forum for that, I'm open to su= ggestions.

Cheers,
- markku
Dr. Markku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK.
=
--000000000000b7f88e059c4868c1-- From nobody Thu Jan 16 13:37:56 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280C1120090 for ; Thu, 16 Jan 2020 13:37:55 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GFce2d7_rQ7 for ; Thu, 16 Jan 2020 13:37:53 -0800 (PST) Received: from esa2.isaracorp.com (esa2.isaracorp.com [207.107.152.176]) (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 3FFEA12008A for ; Thu, 16 Jan 2020 13:37:53 -0800 (PST) IronPort-SDR: yp1YqYPju1LqG8Sv8le/Oj92da/6CoLglVrzJqdy5KphtOQPQhwEW1gwlcZ+EKSNmIL56b8SHp +Zyll5eBcWxDLneHdqrMULAijnGFh+NZEWlMGDeKxgsojo25e5qQl/DVjEXY+XzF2bnR+VD1UA hDV+0tqDDEjNoSOt5TmWJsV9KUNRykfT8t1kd7DVAkbF8nAQxem7AH5kEerXsnl4DXw6S+7VBF 9fOczWdAmWPZoNBe9yrhn/PiWMnuVx0kZbOVlTiqEQuxRk7Ph77USJkmQlHRTADfZluNu0FODM 9HM= Received: from unknown (HELO V0501WEXGPR02.isaracorp.com) ([10.5.9.20]) by ip2.isaracorp.com with ESMTP; 16 Jan 2020 21:37:50 +0000 Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR02.isaracorp.com (10.5.9.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1847.3; Thu, 16 Jan 2020 16:38:26 -0500 Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1847.005; Thu, 16 Jan 2020 16:38:26 -0500 From: Daniel Van Geest To: Stephen Farrell , Mike Ounsworth , IETF SecDispatch Thread-Topic: [External]Re: [Secdispatch] Can Composite sigs move back to LAMPS? Thread-Index: AdXMlh5Ba3U4rdZGTG6zfD9kbyUHDgANtcoAAASJP4A= Date: Thu, 16 Jan 2020 21:38:26 +0000 Message-ID: <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> In-Reply-To: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.5.52] Content-Type: multipart/alternative; boundary="_000_09B0CA53BAAF413981792A70ADE58632isaracom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 21:37:55 -0000 --_000_09B0CA53BAAF413981792A70ADE58632isaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlcGhlbiwNCg0KT24gMjAyMC0wMS0xNiwgNzoyOCBQTSwgIlNlY2Rpc3BhdGNoIG9uIGJl aGFsZiBvZiBTdGVwaGVuIEZhcnJlbGwiIDxzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Ygc3RlcGhlbi5m YXJyZWxsQGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4+IHdyb3Rl Og0KDQpIaXlhLA0KDQpJJ20gZ3Vlc3NpbmcgaXQnbGwgYmUgbm8gc3VycHJpc2UgdGhhdCBJIHJl Y2tvbiB0aGF0IHdlDQpvdWdodCBub3QgYWRvcHQgZWl0aGVyIHBpZWNlIG9mIHdvcmsgYXQgdGhp cyB0aW1lIChzb3JyeQ0KZm9yIGJlaW5nIHNvIHByZWRpY3RhYmxlbDstKSBJIGNvbnRpbnVlIHRv IHRoaW5rIHdhaXRpbmcNCid0aWxsIHdlIGtub3cgbW9yZSBpcyB3aXNlci4NCg0KW0RWR10gSSB0 aGluayB3ZSBjYW4gYXBwcmVjaWF0ZSB5b3VyIGNvbnNpc3RlbmN5IGF0IGxlYXN0IDotKQ0KDQpJ J2QgYWxzbyBub3RlIHRoYXQgQ1ZFLTIwMjAtMDYwMSBtYXkgKHdoZW4gZnVsbCBkZXRhaWxzDQpl bWVyZ2UpIHByb3ZpZGUgdmVyeSBkaXJlY3QgZXZpZGVuY2UgdGhhdCBzdGFuZGFyZGlzaW5nDQpj cnlwdG9ncmFwaGljIHBhcmFtZXRlciByZXByZXNlbnRhdGlvbnMgYWhlYWQgb2YgcmVhbA0KdW5k ZXJzdGFuZGluZyBvZiB0aGUgYWxnb3JpdGhtcyBhbmQgdGhlaXIgaW1wbGVtZW50YXRpb25zDQph bmQgcmVhbCB1c2VzIGNhbiBiZSBhIGJhZCBwbGFuIHdpdGggaW1wbGljYXRpb25zIHRoYXQNCm9u bHkgaGl0IGRlY2FkZXMgbGF0ZXIuDQoNCltEVkddIEkgdGhpbmsgeW914oCZdmUgaGludGVkIChv ciBzdGF0ZWQgZXhwbGljaXRseSkgYXQgdGhpcyBiZWZvcmUsIGJ1dCBpdA0KY29uZnVzZXMgbWUu IGRyYWZ0LW91bnN3b3J0aC1wcS1jb21wb3NpdGUtc2lncyBkb2VzIG5vdCBhdHRlbXB0IHRvDQpz dGFuZGFyZGl6ZSB0aGUgcGFyYW1ldGVyIHJlcHJlc2VudGF0aW9ucyBvZiBhbnkgY3J5cHRvZ3Jh cGhpYw0KYWxnb3JpdGhtcy4gIEl04oCZcyBqdXN0IGEgZnJhbWV3b3JrIGZvciBjb21iaW5pbmcg b3RoZXIgc3RhbmRhcmRpemVkDQpyZXByZXNlbnRhdGlvbnMuICBJbiB0aGUgUFEgY2FzZSB0aG9z ZSBhcmUgdG8gYmUgc3RhbmRhcmRpemVkDQpzZXBhcmF0ZWx5IGluIHRoZSBmdXR1cmUuICBUaGlz IGRyYWZ0IGNvdWxkIGp1c3QgYXMgd2VsbCBiZSB1c2VkIHRvDQpjb21iaW5lIFJTQSBhbmQgZWxs aXB0aWMgY3VydmUgc2lnbmF0dXJlcy4gIEkgZG9u4oCZdCB3YW50IHRvIHB1dCB3b3Jkcw0KaW4g TWF4IFBhbGHigJlzIG1vdXRoLCBidXQgaGXigJlzIGN1cnJlbnRseSBkZWFsaW5nIHdpdGggYSBu ZXdib3JuIHNvDQpJIHdpbGwgcHJvdmlzaW9uYWxseSBzYXkgSSB0aGluayBjb21iaW5pbmcgY2xh c3NpY2FsIGFsZ29yaXRobXMgdXNpbmcNCnRoaXMgbWV0aG9kIGlzIG9mIGludGVyZXN0IHRvIGhp bS4gIFByb2JhYmx5IHRoZSBkcmFmdCBzaG91bGQgYmUNCnJlbmFtZWQgdG8gZHJhZnQtb3Vuc3dv cnRoLWNvbXBvc2l0ZS1zaWduYXR1cmVzLCBzaW1pbGFybHkgdG8gd2hhdA0Kd2FzIGRvbmUgaW4g SVBTZWNNRSBmb3IgYSBkcmFmdCBjb21iaW5pbmcga2V5IGFncmVlbWVudCBhbGdvcml0aG1zLg0K VGhlcmXigJlzIG5vdGhpbmcgUFEtc3BlY2lmaWMgYWJvdXQgZWl0aGVyIG1lY2hhbmlzbSwgYnV0 IHRoZSBlZmZvcnRzDQphcmUgYmVpbmcgbWFkZSBub3cgaW4gYW50aWNpcGF0aW9uIG9mIHRoZXNl IGFsZ29yaXRobXMgYXJyaXZhbHMsDQprbm93aW5nIGhvdyBsb25nIHRoZSBzdGFuZGFyZGl6YXRp b24gcHJvY2VzcyBjYW4gdGFrZS4NCg0KVGhhbmtzLA0KDQpEYW5pZWwgVmFuIEdlZXN0DQoNCg0K T24gMTYvMDEvMjAyMCAxOToxMywgTWlrZSBPdW5zd29ydGggd3JvdGU6DQpGb2xsb3dpbmcgdXAg b24gaW4tcm9vbSBkaXNjdXNzaW9ucyBhdCAxMDYsIGFuZCB0aGUgZW5zdWluZyBsaXN0DQpkaXNj dXNzaW9ucywgSSdkIGxpa2UgdG8gYXNrIGZvciBjb25maXJtYXRpb24gb2YgdGhlIGZvbGxvd2lu Zw0KcG9pbnRzOg0KMS4gVGhlcmUgaXMgZW5vdWdoIGludGVyZXN0IGluIGFuIG9idmlvdXMtYW5k LXN0cmFpZ2h0Zm9yd2FyZA0KaW1wbGVtZW50YXRpb24gb2YgY29tcG9zaXRlIHNpZ25hdHVyZXMg dG8gY29udGludWUgd29ya2luZyBvbiBpdD8gMWEuDQpUaGUgY3VycmVudCBkcmFmdCBmb3IgdGhp cyBpcyBkcmFmdC1vdW5zd29ydGgtcHEtY29tcG9zaXRlLXNpZ3MtMDINCjIuIFNlY0Rpc3BhdGNo IGlzIGFzc2lnbmluZyB0aGlzIGJhY2sgdG8gTEFNUFM/IDJhLiBUaGUgY3VycmVudCBkcmFmdA0K bWlnaHQgbm90IGJlIHRoZSBtb3N0IG9idmlvdXMtYW5kLXN0cmFpZ2h0Zm9yd2FyZCBpbXBsZW1l bnRhdGlvbjsNCndlJ3JlIHdpbGxpbmcgdG8gc2ltcGxpZnkgdW50aWwgaXQncyBpbi1zY29wZSBm b3IgTEFNUFMuDQotLS0gTWlrZSBPdW5zd29ydGggU29mdHdhcmUgU2VjdXJpdHkgQXJjaGl0ZWN0 LCBFbnRydXN0IERhdGFjYXJkDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBTZWNkaXNwYXRjaCBtYWlsaW5nDQpsaXN0IFNlY2Rpc3BhdGNoQGlldGYub3Jn PG1haWx0bzpTZWNkaXNwYXRjaEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2VjZGlzcGF0Y2gNCg0K --_000_09B0CA53BAAF413981792A70ADE58632isaracom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0Ei IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFN0ZXBoZW4sPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjAyMC0wMS0xNiwg NzoyOCBQTSwgJnF1b3Q7U2VjZGlzcGF0Y2ggb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFycmVsbCZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlY2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmciPnNl Y2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFp bHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5IaXlhLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5JJ20gZ3Vlc3NpbmcgaXQnbGwgYmUgbm8gc3VycHJpc2UgdGhhdCBJ IHJlY2tvbiB0aGF0IHdlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5vdWdodCBub3QgYWRvcHQgZWl0 aGVyIHBpZWNlIG9mIHdvcmsgYXQgdGhpcyB0aW1lIChzb3JyeTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Zm9yIGJlaW5nIHNvIHByZWRpY3RhYmxlbDstKSBJIGNvbnRpbnVlIHRvIHRoaW5rIHdhaXRp bmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPid0aWxsIHdlIGtub3cgbW9yZSBpcyB3aXNlci48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+W0RWR10gSSB0aGluayB3ZSBjYW4gYXBwcmVjaWF0ZSB5b3Vy IGNvbnNpc3RlbmN5IGF0IGxlYXN0IDotKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5JJ2QgYWxzbyBub3RlIHRoYXQgQ1ZFLTIwMjAtMDYwMSBtYXkg KHdoZW4gZnVsbCBkZXRhaWxzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5lbWVyZ2UpIHByb3ZpZGUg dmVyeSBkaXJlY3QgZXZpZGVuY2UgdGhhdCBzdGFuZGFyZGlzaW5nPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5jcnlwdG9ncmFwaGljIHBhcmFtZXRlciByZXByZXNlbnRhdGlvbnMgYWhlYWQgb2YgcmVh bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+dW5kZXJzdGFuZGluZyBvZiB0aGUgYWxnb3JpdGhtcyBh bmQgdGhlaXIgaW1wbGVtZW50YXRpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5hbmQgcmVhbCB1 c2VzIGNhbiBiZSBhIGJhZCBwbGFuIHdpdGggaW1wbGljYXRpb25zIHRoYXQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPm9ubHkgaGl0IGRlY2FkZXMgbGF0ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PltEVkddIEkgdGhpbmsgeW914oCZdmUgaGludGVkIChvciBzdGF0ZWQgZXhwbGljaXRseSkgYXQg dGhpcyBiZWZvcmUsIGJ1dCBpdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Y29uZnVzZXMgbWUuIGRyYWZ0LW91bnN3b3J0aC1wcS1jb21wb3NpdGUtc2lncyBkb2VzIG5vdCBh dHRlbXB0IHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zdGFuZGFyZGl6 ZSB0aGUgcGFyYW1ldGVyIHJlcHJlc2VudGF0aW9ucyBvZiBhbnkgY3J5cHRvZ3JhcGhpYzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWxnb3JpdGhtcy4mbmJzcDsgSXTigJlz IGp1c3QgYSBmcmFtZXdvcmsgZm9yIGNvbWJpbmluZyBvdGhlciBzdGFuZGFyZGl6ZWQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlcHJlc2VudGF0aW9ucy4mbmJzcDsgSW4g dGhlIFBRIGNhc2UgdGhvc2UgYXJlIHRvIGJlIHN0YW5kYXJkaXplZDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VwYXJhdGVseSBpbiB0aGUgZnV0dXJlLiZuYnNwOyBUaGlz IGRyYWZ0IGNvdWxkIGp1c3QgYXMgd2VsbCBiZSB1c2VkIHRvPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5jb21iaW5lIFJTQSBhbmQgZWxsaXB0aWMgY3VydmUgc2lnbmF0dXJl cy4mbmJzcDsgSSBkb27igJl0IHdhbnQgdG8gcHV0IHdvcmRzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5pbiBNYXggUGFsYeKAmXMgbW91dGgsIGJ1dCBoZeKAmXMgY3VycmVu dGx5IGRlYWxpbmcgd2l0aCBhIG5ld2Jvcm4gc288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgd2lsbCBwcm92aXNpb25hbGx5IHNheSBJIHRoaW5rIGNvbWJpbmluZyBjbGFz c2ljYWwgYWxnb3JpdGhtcyB1c2luZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+dGhpcyBtZXRob2QgaXMgb2YgaW50ZXJlc3QgdG8gaGltLiZuYnNwOyBQcm9iYWJseSB0aGUg ZHJhZnQgc2hvdWxkIGJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZW5h bWVkIHRvIGRyYWZ0LW91bnN3b3J0aC1jb21wb3NpdGUtc2lnbmF0dXJlcywgc2ltaWxhcmx5IHRv IHdoYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndhcyBkb25lIGluIElQ U2VjTUUgZm9yIGEgZHJhZnQgY29tYmluaW5nIGtleSBhZ3JlZW1lbnQgYWxnb3JpdGhtcy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJl4oCZcyBub3RoaW5nIFBRLXNw ZWNpZmljIGFib3V0IGVpdGhlciBtZWNoYW5pc20sIGJ1dCB0aGUgZWZmb3J0czxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXJlIGJlaW5nIG1hZGUgbm93IGluIGFudGljaXBh dGlvbiBvZiB0aGVzZSBhbGdvcml0aG1zIGFycml2YWxzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+a25vd2luZyBob3cgbG9uZyB0aGUgc3RhbmRhcmRpemF0aW9uIHByb2Nl c3MgY2FuIHRha2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGFuaWVsIFZhbiBHZWVzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPk9uIDE2LzAxLzIwMjAgMTk6MTMsIE1pa2UgT3Vuc3dvcnRoIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdp bi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGNtIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Rm9sbG93aW5nIHVwIG9uIGluLXJvb20gZGlzY3Vzc2lvbnMgYXQgMTA2 LCBhbmQgdGhlIGVuc3VpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ZGlzY3Vzc2lvbnMs IEknZCBsaWtlIHRvIGFzayBmb3IgY29uZmlybWF0aW9uIG9mIHRoZSBmb2xsb3dpbmc8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPnBvaW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjEuIFRoZXJlIGlz IGVub3VnaCBpbnRlcmVzdCBpbiBhbiBvYnZpb3VzLWFuZC1zdHJhaWdodGZvcndhcmQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPmltcGxlbWVudGF0aW9uIG9mIGNvbXBvc2l0ZSBzaWduYXR1cmVzIHRv IGNvbnRpbnVlIHdvcmtpbmcgb24gaXQ/IDFhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIGN1 cnJlbnQgZHJhZnQgZm9yIHRoaXMgaXMgZHJhZnQtb3Vuc3dvcnRoLXBxLWNvbXBvc2l0ZS1zaWdz LTAyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4yLiBTZWNEaXNwYXRjaCBpcyBhc3NpZ25pbmcgdGhp cyBiYWNrIHRvIExBTVBTPyAyYS4gVGhlIGN1cnJlbnQgZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPm1pZ2h0IG5vdCBiZSB0aGUgbW9zdCBvYnZpb3VzLWFuZC1zdHJhaWdodGZvcndhcmQgaW1w bGVtZW50YXRpb247PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij53ZSdyZSB3aWxsaW5nIHRvIHNpbXBs aWZ5IHVudGlsIGl0J3MgaW4tc2NvcGUgZm9yIExBTVBTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ LS0tIE1pa2UgT3Vuc3dvcnRoIFNvZnR3YXJlIFNlY3VyaXR5IEFyY2hpdGVjdCwgRW50cnVzdCBE YXRhY2FyZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gU2VjZGlzcGF0Y2ggbWFpbGluZzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+bGlzdCA8YSBocmVmPSJtYWlsdG86U2VjZGlzcGF0Y2hAaWV0Zi5vcmciPg0KU2VjZGlz cGF0Y2hAaWV0Zi5vcmc8L2E+IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_09B0CA53BAAF413981792A70ADE58632isaracom_-- From nobody Fri Jan 17 04:11:07 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8912003F for ; Fri, 17 Jan 2020 04:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 npdmrbPl-b1C for ; Fri, 17 Jan 2020 04:11:00 -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 7F44A12001B for ; Fri, 17 Jan 2020 04:10:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3B2DBE20; Fri, 17 Jan 2020 12:10:57 +0000 (GMT) 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 18nqRScVEUkl; Fri, 17 Jan 2020 12:10:57 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 60A8EBDCF; Fri, 17 Jan 2020 12:10:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579263057; bh=sy8NnRChMHMM6cxPK+TUN2zwlRAE5lF4tRvh+fQmiME=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JpFMI8KL79faoYTIK4ZZVjjMYhLFWuent80JC9iT+GHQhMkoLIUv+zA16FCXzVvPt 9s24qytAk4nfZqPJEtOpBYUnc46IkF/ldEnXsLLJ3Z9MrrbMPlM40exhpqMbyb4YBP DT1wuZwcoW4Yac+gx9v2rnE0lIw6AofyWP25r1EM= To: Daniel Van Geest , Mike Ounsworth , IETF SecDispatch References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> From: Stephen Farrell 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: Fri, 17 Jan 2020 12:10:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="84wL367M0gV2c99Jwp2RPaQIk8nLK3ZE4" Archived-At: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 12:11:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --84wL367M0gV2c99Jwp2RPaQIk8nLK3ZE4 Content-Type: multipart/mixed; boundary="Qt6fV4rP8vPspVbEayJ2e3FjjWLxcIMaP"; protected-headers="v1" From: Stephen Farrell To: Daniel Van Geest , Mike Ounsworth , IETF SecDispatch Message-ID: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> In-Reply-To: <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> --Qt6fV4rP8vPspVbEayJ2e3FjjWLxcIMaP Content-Type: multipart/mixed; boundary="------------3968FCAA65AB01DFE859AA12" Content-Language: en-US This is a multi-part message in MIME format. --------------3968FCAA65AB01DFE859AA12 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 16/01/2020 21:38, Daniel Van Geest wrote: > Hi Stephen, >=20 > On 2020-01-16, 7:28 PM, "Secdispatch on behalf of Stephen Farrell" > on > behalf of > stephen.farrell@cs.tcd.ie> wrote: >=20 > Hiya, >=20 > I'm guessing it'll be no surprise that I reckon that we ought not > adopt either piece of work at this time (sorry for being so > predictablel;-) I continue to think waiting 'till we know more is > wiser. >=20 > [DVG] I think we can appreciate your consistency at least :-) You're welcome:-) > I'd also note that CVE-2020-0601 may (when full details emerge) > provide very direct evidence that standardising cryptographic > parameter representations ahead of real understanding of the > algorithms and their implementations and real uses can be a bad plan > with implications that only hit decades later. >=20 > [DVG] I think you=E2=80=99ve hinted (or stated explicitly) at this befo= re, > but it confuses me. draft-ounsworth-pq-composite-sigs does not > attempt to standardize the parameter representations of any > cryptographic algorithms. It=E2=80=99s just a framework for combining = other > standardized representations. In the PQ case those are to be > standardized separately in the future. This draft could just as well > be used to combine RSA and elliptic curve signatures.=20 So I really don't see any benefit in a new complex way to combine RSA and ECC signatures. I do see many costs and risks. My conclusion is that this stuff could only really be useful enough to justify the costs if we have PQ signature schemes that are considered stable enough to deploy but where we don't yet fully trust the algorithms to the point where we'd be happy to depend solely on those new algorithms. In that context, ISTM that creating the scope for CVE-20YY-NNNN (analogous to CVE-2020-0601) is a very real risk among others that were already mentioned earlier in discussion. (*) Cheers, S. (*) I brought up CVE-2020-0601 not as a killer-argument that summarises the entire thread, but because the CVE is new information (even if we're still unsure of all the details) and I don't recall that specific risk having come up in the discussion so far. > I don=E2=80=99t want > to put words in Max Pala=E2=80=99s mouth, but he=E2=80=99s currently de= aling with a > newborn so I will provisionally say I think combining classical > algorithms using this method is of interest to him. Probably the > draft should be renamed to draft-ounsworth-composite-signatures, > similarly to what was done in IPSecME for a draft combining key > agreement algorithms. There=E2=80=99s nothing PQ-specific about either > mechanism, but the efforts are being made now in anticipation of > these algorithms arrivals, knowing how long the standardization > process can take. >=20 > Thanks, >=20 > Daniel Van Geest >=20 >=20 > On 16/01/2020 19:13, Mike Ounsworth wrote: Following up on in-room > discussions at 106, and the ensuing list discussions, I'd like to ask > for confirmation of the following points: 1. There is enough interest > in an obvious-and-straightforward implementation of composite > signatures to continue working on it? 1a. The current draft for this > is draft-ounsworth-pq-composite-sigs-02 2. SecDispatch is assigning > this back to LAMPS? 2a. The current draft might not be the most > obvious-and-straightforward implementation; we're willing to simplify > until it's in-scope for LAMPS. --- Mike Ounsworth Software Security > Architect, Entrust Datacard=20 > _______________________________________________ Secdispatch mailing=20 > list Secdispatch@ietf.org=20 > https://www.ietf.org/mailman/listinfo/secdispatch >=20 >=20 > _______________________________________________ Secdispatch mailing > list Secdispatch@ietf.org=20 > https://www.ietf.org/mailman/listinfo/secdispatch >=20 --------------3968FCAA65AB01DFE859AA12 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------3968FCAA65AB01DFE859AA12-- --Qt6fV4rP8vPspVbEayJ2e3FjjWLxcIMaP-- --84wL367M0gV2c99Jwp2RPaQIk8nLK3ZE4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4hpFAACgkQWrL68XsX K+o/phAAtj689wMskgJRhqzB7orLknxBuL4SXuFINE47lkv5f/w1lexZsRX3oL1e Y0cXv0dKMv1qOeqEb67CSWz64awIFEuB3N7ztxfkn8LQMAF9SLtDom0vNNiHPmmI J+xRD3crqC7wCgQrpz8OuvijbfNLdrH4CMsHUwLqcVlY/XMDUM/nrXtTqQDjlsSb s4SLg+d2rLcD1p+cD4sPSWv4i3sx5o5j0hu1Aa7RvBecTZEBO4gSmBSKWNtXUQCZ pvbZnZLUvZb87XBYp8X31yCOanCyQhcctfyzgw/BTQjg485fvAOHbD8zweHQfisS vPBZNBRb7a72RVpja1N8nKK0F7CXGnIswl+D//h/XAA01pCP2aPfCUCJ8r9ljMBi MhwAtrUcFEYGvzEkCaAN73MFtuBpQkH2+SUJ3o4Nbi3kC1htUHOf/ztM+aq4pNS9 sAHWO8M8dHc/HchbhYQ2BIRiAGl0AwovgHnWFu+FiyTB5cCGnZNq4UgJqx2GRaHg 87HG9d0Yu0O5UNoM0JcDYZ+3vwSEg8gx2doX9X5AJaXzBtnTxw+7aTZtZKOH+1pu QnrZ7DAkgZTEHNLMwq1YvLLyc8U7k2dxKtlL5zOApRP8yLZfTtr6mqCdDi2eFVBh FBbpbiNrC3dKK6LGLRcmqJpA6NqQVnEPEk+PVsuiw0cbaJMHdwc= =TBlT -----END PGP SIGNATURE----- --84wL367M0gV2c99Jwp2RPaQIk8nLK3ZE4-- From nobody Fri Jan 17 04:22:50 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE5912001B for ; Fri, 17 Jan 2020 04:22:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pqshield-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmMLMBDVkl80 for ; Fri, 17 Jan 2020 04:22:47 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 781C112001A for ; Fri, 17 Jan 2020 04:22:47 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id c16so22454729qko.6 for ; Fri, 17 Jan 2020 04:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6rwufNdlZ2fAldnWfjqEfwEwUELsDx5yZejpk5OWITw=; b=MyYYupoEsGCLvY4tST3Yti3RNQPzD5l8OsCL8cSTRH1Hx9JiLf/EoDNuDgV9ct91m/ 7Lrg8tMmd/l7w4lxPqsPHUxTe1kzyjCS+BfvO2XpkhcVNQUPHptxp5RJX/WJniNrof9t J717UBBKX+kHxWu9T2czniZB4zyrvor+RZOlvysE+wgUqXuh11vfr022fYtrvzX3ytMM NKkyNnZ/7YnZVLxNRBPWhXDS90R6ziUrvxuzmbP6nRML6/b3ReMUPdH3pdctUMhJ43qe ryLQUQawwxPEmtnwhkkoUpdO1ctp3K604eXdN3txI3lDYjS7IsMoVeQXzSPc4E7eH6Nm tubA== 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=6rwufNdlZ2fAldnWfjqEfwEwUELsDx5yZejpk5OWITw=; b=ePuhjM7t5FYHhkSu5ri4TP0IQmodT5VB2tzurGvYH+Pnsy77NPVaxfyEklpmPMwZMQ pU/+4tVikUI51i2e3r6BPRYk9zFZxP5rmxcPFe6Hg8UZ72ANUxDThtJ3h0l3y4/fiyS3 TqwyzCuNi41oalHCu1kM1y2FPjavVmOSn/IqG1hUKmX7cFzx5iyHOtDz5QLg6NcR/8VD 5KYpS91K2iJQxAVsU+uk34pL8VyS6Sw5o3xbuwFe18HRr3FGweZi7hzjVyCf/lbP6CME XoYYTyfiN9Eu1bleTsejxWAQ9y77qo5TJuKgXBpADIGLvnnReWlskQrrjg9e9ErJ7E+0 TBTQ== X-Gm-Message-State: APjAAAX8QvRs0cf5KeJ48nUWGdlmP0PZ1lwaIiytKOAeO9iBB5P3dvsQ eScZ518CbocrptLMM6ISLHTqU4hiiARim1ZVMOY6Mw== X-Google-Smtp-Source: APXvYqwNgmDqnlTTWiZuwLoG7RcVtlwSPJZ9slo1LcSQS/GBXWI1L8EEPbiufqXjF7lYHwgMuuOzijQ6ud2IXNafZzo= X-Received: by 2002:a37:a5c7:: with SMTP id o190mr33497313qke.355.1579263766654; Fri, 17 Jan 2020 04:22:46 -0800 (PST) MIME-Version: 1.0 References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> In-Reply-To: From: "Markku-Juhani O. Saarinen" Date: Fri, 17 Jan 2020 12:22:35 +0000 Message-ID: To: Stephen Farrell Cc: Daniel Van Geest , Mike Ounsworth , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000d183c9059c54ff45" Archived-At: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 12:22:49 -0000 --000000000000d183c9059c54ff45 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 12:11 PM Stephen Farrell wrote: > My conclusion is that this stuff could only really be useful > enough to justify the costs if we have PQ signature schemes > that are considered stable enough to deploy but where we > don't yet fully trust the algorithms to the point where we'd > be happy to depend solely on those new algorithms. Thanks for your support. That is exactly where we are and what the stated purpose of draft-ounsworth-pq-composite-sigs-02 is. Cheers, - markku Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. --000000000000d183c9059c54ff45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 12:11 PM Stephen = Farrell <stephen.farrell@cs= .tcd.ie> wrote:

My conclusion is that this stuff could only really be useful
enough to justify the costs if we have PQ signature schemes
that are considered stable enough to deploy but where we
don't yet fully trust the algorithms to the point where we'd
be happy to depend solely on those new algorithms.

Thanks for your support. That is exactly where we are and what the= stated purpose of draft-ounsworth-pq-composite-sigs-02 is.

<= /div>
Cheers,
- markku

Dr. Markku-Juhani O. Sa= arinen <mjos@pqsh= ield.com> PQShield, Oxford UK.
=C2=A0
--000000000000d183c9059c54ff45-- From nobody Fri Jan 17 04:30:37 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9EA120046 for ; Fri, 17 Jan 2020 04:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 dUMMrrhrsNlK for ; Fri, 17 Jan 2020 04:30:32 -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 5696712003F for ; Fri, 17 Jan 2020 04:30:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 17E8DBE20; Fri, 17 Jan 2020 12:30:31 +0000 (GMT) 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 jyA0aNVpCMV0; Fri, 17 Jan 2020 12:30:30 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C4CC9BDCF; Fri, 17 Jan 2020 12:30:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579264230; bh=MlYjrocARTD9eA1u+qDprSesyQOeFp6VJ1Aqr7M9tVQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cBQxux6EHPLEsWUhkkqkey6huq2dZ2+F0aG3zivwvJHYeWajQjOp2YMSbMnqVOtoZ l5ZWkJpXEMhrwUO0465SN3PYc0L6+zjFiJjGVWNEYUtzT2kf1UoDR4YKsfsGYA10WN aDB4l6dYfgBvUu70hjb5h+l3TlMWRIyzwe659KB4= To: "Markku-Juhani O. Saarinen" Cc: Daniel Van Geest , IETF SecDispatch , Mike Ounsworth References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> From: Stephen Farrell 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: <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> Date: Fri, 17 Jan 2020 12:30:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hHkvBgXryzbz9TOcT9Nh59kUIoaRy7xtH" Archived-At: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 12:30:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hHkvBgXryzbz9TOcT9Nh59kUIoaRy7xtH Content-Type: multipart/mixed; boundary="ikdCRcs4VbW402WDvGRVZsDblPWPQXkkm"; protected-headers="v1" From: Stephen Farrell To: "Markku-Juhani O. Saarinen" Cc: Daniel Van Geest , IETF SecDispatch , Mike Ounsworth Message-ID: <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> In-Reply-To: --ikdCRcs4VbW402WDvGRVZsDblPWPQXkkm Content-Type: multipart/mixed; boundary="------------3A2B6193ABDD6E9FD7316E52" Content-Language: en-US This is a multi-part message in MIME format. --------------3A2B6193ABDD6E9FD7316E52 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/01/2020 12:22, Markku-Juhani O. Saarinen wrote: > On Fri, Jan 17, 2020 at 12:11 PM Stephen Farrell > wrote: >=20 >> > My conclusion is that this stuff could only really be useful >> enough to justify the costs if we have PQ signature schemes >> that are considered stable enough to deploy but where we >> don't yet fully trust the algorithms to the point where we'd >> be happy to depend solely on those new algorithms. >=20 >=20 > Thanks for your support. That is exactly where we are=20 I hope it's clear I disagree with you - IMO the conditions above are not satisfied today and I do not support adopting such work at this time. Were I to guess and be optimistic it might be worth re-considering the topic in a year or so. S. > and what the stated > purpose of draft-ounsworth-pq-composite-sigs-02 is. >=20 > Cheers, > - markku >=20 > Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. >=20 >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch >=20 --------------3A2B6193ABDD6E9FD7316E52 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------3A2B6193ABDD6E9FD7316E52-- --ikdCRcs4VbW402WDvGRVZsDblPWPQXkkm-- --hHkvBgXryzbz9TOcT9Nh59kUIoaRy7xtH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4hqOUACgkQWrL68XsX K+oHeg//YJkHY25maYKVRrwrS45BVtxj5w/8orR8GAYaB64SxPNKqBuxBGrovcYE TjUD95gK+uI33xbpDmtG0dqCmOzhfCmwkHJjNrPtG0PtRO4T4mPN819W9U62yHyR VfFaKPoVKyF/l9H3x5P35CPsL4IOTIgVKJo4BX/YLMh8jo/eGvvA8qG9MG+cdJ0i CxjBIiAaioOD4NkLOjTAkj+tr3alZbGwFOTjeYmHP10OB5EqENDJfekVM/OtT1Sr EU/pkzglI9mUmXuopfjmZlqFfpW9RseyOt/bKsCwWhHfHnXAcdNBWvPVFTG137JO Qwj4lZNX6LSzQQEyEgd2pFwilg+Z20aNP5PlpQxaVZxq44fOnr4moOoAPe2XJ4HW 6wp2M4b7jdTVTvOj9YsaREdvsfHQ0jCyMUwazjxXuay6s+7oTb1C0OOSV8JHS89v 3zDoquSgZ2ZV4c/lCP5qKg8qg5S1hIX3wP/lmt+k4L/jgP2tuc7/J8Xm87Yi9BzY 0Lt53siXCTb8aCC1y3lVR7LlkTlazzvRUclztNDw/trC4pXK/z5ZZBjtojI8rco9 8wZ7fBw7uyt07n2OhAPUJ2Es5Tsij+Xczn39wW1eXnQU1+hqNeEGH3HHmV57BmH4 pTN2B3eyT3zrCaH0tWEJBhRnLam6nzBgW4SH1P7TQHFSRwPBM8o= =aWEA -----END PGP SIGNATURE----- --hHkvBgXryzbz9TOcT9Nh59kUIoaRy7xtH-- From nobody Fri Jan 17 09:54:33 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7861200E5 for ; Fri, 17 Jan 2020 09:54:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQOk8At3jye5 for ; Fri, 17 Jan 2020 09:54:29 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D8F1200A3 for ; Fri, 17 Jan 2020 09:54:27 -0800 (PST) IronPort-SDR: cubn1L7g5gUfWL80QE6qu6tBy2zhpAgWBLXD5Mv4lfnl4SZ7k/WzU8tE3GzTs03dvrDMKXAMPW PivTXz9+qV3g== X-IronPort-AV: E=Sophos;i="5.70,331,1574143200"; d="scan'208";a="7753627" Received: from pmspex04.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.51]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 17 Jan 2020 11:54:27 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by PMSPEX04.corporate.datacard.com (192.168.211.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jan 2020 11:54:27 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 17 Jan 2020 11:54:26 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CXFjUHFGyiLZ2MIXuy+rr4uUdGs+KRjoLF+I5SnlBFNuDgU+Jlb6WV3y09mMnpm3wQ34yQssvoYIQEUM+AHIkdeG2l7gkE4jtGz0PsYQz6LcwltniOsjCO4wK6x0zTwOix6zGrG/ptV4H4Zl21JDeelGBTKN9n5HF7fjFwi2HDD/RBg24bNHpq+Uwwb6W8nrvNrtuXrcN1v2mcpByW0aMPx3wagpWMEdzNLE+qOGWVXyBkWpbJhJ4AieUK+mLoHKZGp9lZK6W1ZWl7vVQt1GBw4W56Ed1KtFlcwL8L54xwnzZbMkNQXquLCrpSMGn3r4SxYkvUU6Vg09JJ9I1s5oeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x8RGT3EHd0e1LNGz4uyCCpzDMZJ7EVkjvkNxUNCO2dA=; b=JLZ6jlruvhw8CBbizLSSfwNvrRf8cUK77OLZLtNf/7tX4qEi5D4eSsI1Van/goHAAbvZ/be+mHU0tzeVSv2sw2sJWMxYroIyvEbHeT1sILbhdzbMF3GdkCUCIb1Awxt0qMmM2aaHI6eohQ7yhEC+sdjCr7NlWXSrORfxebYIhG3id39O7qDEWOglGYir7e5kzV9loWepIBMlw1045xdspZDJn9Ehne3Fo1RsooJNDr9wUBdhiduXs1V65jKAUGCiyoK66GBnH/YkpAMRHlX/+1arORDptqz6xElJKlDm0GVH/w7PWFSDoHGR7qNM5dslto5/RyIz3AeMvXCtmVzHJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x8RGT3EHd0e1LNGz4uyCCpzDMZJ7EVkjvkNxUNCO2dA=; b=TbbAze2qrY94+JYX5k0ce312dPSIEZSsSExqBbsL7CLmZQU2VEA8YjNaQkC3BSRhx64GaXdOAb1vcUWU2skJLLpaEfCchp90JEE0j2KjBaXaDbExs144dNeCXLS6QIEWrEsDSk+khDTsDyopiuRev6ecVk1N6gB4LSKxPUApYrw= Received: from DM6PR11MB3883.namprd11.prod.outlook.com (10.255.61.32) by DM6PR11MB3052.namprd11.prod.outlook.com (20.177.218.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 17 Jan 2020 17:54:25 +0000 Received: from DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392]) by DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392%6]) with mapi id 15.20.2644.023; Fri, 17 Jan 2020 17:54:25 +0000 From: Mike Ounsworth To: Stephen Farrell , "Markku-Juhani O. Saarinen" CC: Daniel Van Geest , IETF SecDispatch Thread-Topic: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS? Thread-Index: AQHVzS8z4XsT5+vb5UScUzn4/98hV6fuxzqAgAACNYCAAFmCYA== Date: Fri, 17 Jan 2020 17:54:25 +0000 Message-ID: References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> In-Reply-To: <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [70.76.144.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12d5c148-7ed2-412d-ffd8-08d79b764a93 x-ms-traffictypediagnostic: DM6PR11MB3052: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(366004)(376002)(39850400004)(199004)(189003)(71200400001)(5660300002)(66556008)(64756008)(66946007)(76116006)(8676002)(8936002)(66476007)(81156014)(4326008)(54906003)(316002)(81166006)(296002)(110136005)(33656002)(66446008)(9686003)(478600001)(186003)(55016002)(7696005)(52536014)(86362001)(26005)(6506007)(2906002)(53546011)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB3052; H:DM6PR11MB3883.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JhtfbgD2Ho7wD928MwIp/XqRbQo+rYNhepLDonjNfJgkrt+PjZaEtfI3LZvPYzk8/TuPGNYUd1kLjAbogItuH5nWCEwEFQS2ZsfuMN919D5HkaoUF/6hQ/rDfI8peJU9joSy1kAoDaGYaN+ac0G4xV5cwEkln3diKJX7wvA4loyyJZuBUB5kR+eh3aYJZt95jSn2pOq4cszlJDgEjGcB5g4ahSMM/hakV8WoRj5w7y1bYvzIHgm/7EQPWEcX3kcHHaJ5/wjLuFfoS7ZU+4WWpjAF8BbW/+Y+uB0aoRNT6P0ld+r5+bRt2e8GoSkn1DBPqARQIlPz4cCvFQ90smeD7q2vXhIW7K4CDTtZOo+2X3jnwe17M+C17ZkTO1naV/L7jQ0ubyiJPb13HSr8NdLzJGQA/7e2xmRMCz4ODcwmvenUudEXVnfbY11pSboF+BBTBkEbGQUlv41dvJOxPDS+qA9HEev+Ys5+xz3eX85jox8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 12d5c148-7ed2-412d-ffd8-08d79b764a93 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 17:54:25.4464 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkEyQXl0fzr6GjAJBFnvU7AedAz3XScGcwpXvhQY9MuvN6TERwoekqhvkLMR7teQUpRrkm4pN6B0IRp6IbuOo6rDiR0C4QFV6wgaa+Fm6QzAjJCAklnAmtaH8j7uvBkd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3052 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 17:54:31 -0000 PiBXZXJlIEkgdG8gZ3Vlc3MgYW5kIGJlIG9wdGltaXN0aWMgaXQgbWlnaHQgYmUgd29ydGggcmUt Y29uc2lkZXJpbmcgdGhlIHRvcGljIGluIGEgeWVhciBvciBzby4NCg0KQ29vbC4gSW4gdGhlIG1l YW50aW1lLCB3ZSBwbGFuIHRvIGtlZXAgd29ya2luZyBvbiB0aGUgb3V0c3RhbmRpbmcgVE9ETyBk ZWNpc2lvbiBwb2ludHMgaW4gdGhlIGRyYWZ0IGFzIG1vcmUgdmVuZG9ycyBhcHByb2FjaCB1cyBm b3IgaW50ZXJvcCB0ZXN0aW5nLiA6LSkNCg0KLS0tDQpNaWtlIE91bnN3b3J0aCB8IE9mZmljZTog KzEgKDYxMykgMjcwLTI4NzMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0 ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gDQpTZW50OiBKYW51YXJ5 IDE3LCAyMDIwIDY6MzAgQU0NClRvOiBNYXJra3UtSnVoYW5pIE8uIFNhYXJpbmVuIDxtam9zQHBx c2hpZWxkLmNvbT4NCkNjOiBEYW5pZWwgVmFuIEdlZXN0IDxEYW5pZWwuVmFuR2Vlc3RAaXNhcmEu Y29tPjsgSUVURiBTZWNEaXNwYXRjaCA8c2VjZGlzcGF0Y2hAaWV0Zi5vcmc+OyBNaWtlIE91bnN3 b3J0aCA8TWlrZS5PdW5zd29ydGhAZW50cnVzdGRhdGFjYXJkLmNvbT4NClN1YmplY3Q6IFtFWFRF Uk5BTF1SZTogW1NlY2Rpc3BhdGNoXSBDYW4gQ29tcG9zaXRlIHNpZ3MgbW92ZSBiYWNrIHRvIExB TVBTPw0KDQoNCg0KT24gMTcvMDEvMjAyMCAxMjoyMiwgTWFya2t1LUp1aGFuaSBPLiBTYWFyaW5l biB3cm90ZToNCj4gT24gRnJpLCBKYW4gMTcsIDIwMjAgYXQgMTI6MTEgUE0gU3RlcGhlbiBGYXJy ZWxsIA0KPiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4NCj4gd3JvdGU6DQo+IA0KPj4NCj4g TXkgY29uY2x1c2lvbiBpcyB0aGF0IHRoaXMgc3R1ZmYgY291bGQgb25seSByZWFsbHkgYmUgdXNl ZnVsDQo+PiBlbm91Z2ggdG8ganVzdGlmeSB0aGUgY29zdHMgaWYgd2UgaGF2ZSBQUSBzaWduYXR1 cmUgc2NoZW1lcyB0aGF0IGFyZSANCj4+IGNvbnNpZGVyZWQgc3RhYmxlIGVub3VnaCB0byBkZXBs b3kgYnV0IHdoZXJlIHdlIGRvbid0IHlldCBmdWxseSB0cnVzdCANCj4+IHRoZSBhbGdvcml0aG1z IHRvIHRoZSBwb2ludCB3aGVyZSB3ZSdkIGJlIGhhcHB5IHRvIGRlcGVuZCBzb2xlbHkgb24gDQo+ PiB0aG9zZSBuZXcgYWxnb3JpdGhtcy4NCj4gDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgc3VwcG9y dC4gVGhhdCBpcyBleGFjdGx5IHdoZXJlIHdlIGFyZQ0KDQpJIGhvcGUgaXQncyBjbGVhciBJIGRp c2FncmVlIHdpdGggeW91IC0gSU1PIHRoZSBjb25kaXRpb25zIGFib3ZlIGFyZSBub3Qgc2F0aXNm aWVkIHRvZGF5IGFuZCBJIGRvIG5vdCBzdXBwb3J0IGFkb3B0aW5nIHN1Y2ggd29yayBhdCB0aGlz IHRpbWUuIFdlcmUgSSB0byBndWVzcyBhbmQgYmUgb3B0aW1pc3RpYyBpdCBtaWdodCBiZSB3b3J0 aCByZS1jb25zaWRlcmluZyB0aGUgdG9waWMgaW4gYSB5ZWFyIG9yIHNvLg0KDQpTLg0KDQo+IGFu ZCB3aGF0IHRoZSBzdGF0ZWQNCj4gcHVycG9zZSBvZiBkcmFmdC1vdW5zd29ydGgtcHEtY29tcG9z aXRlLXNpZ3MtMDIgaXMuDQo+IA0KPiBDaGVlcnMsDQo+IC0gbWFya2t1DQo+IA0KPiBEci4gTWFy a2t1LUp1aGFuaSBPLiBTYWFyaW5lbiA8bWpvc0BwcXNoaWVsZC5jb20+IFBRU2hpZWxkLCBPeGZv cmQgVUsuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+IFNlY2Rpc3BhdGNoQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2gN Cj4gDQo= From nobody Fri Jan 17 10:08:21 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D312007A for ; Fri, 17 Jan 2020 10:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 FJbQHxL0IELx for ; Fri, 17 Jan 2020 10:08:14 -0800 (PST) Received: from st43p00im-zteg10062001.me.com (st43p00im-zteg10062001.me.com [17.58.63.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCF712008B for ; Fri, 17 Jan 2020 10:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1579284488; bh=G7ZCBfzgfjRP+43DWT3PHP20V+hrRVrgaRDkF+yOQK8=; h=From:Message-Id:Content-Type:Subject:Date:To; b=c8duBAIDCiUBnJCO6hIFHASfkjdSnGrZqnUV0Guasgmm36V3hXVVl0v0eRsLi9rsb ogrcPqj1tLCc+n9JUeG8Bos1h0Wy11jVKxPX5BHa/Wxlv1R/FqGQf61NCFFXeJ521c +2Lkxz6+mR8mE7UMXm+ZtJCq7ZfDJYEJ4wj6Kk1GQfxr7eDN6ovp2vBayJ1F52XrwK mVvc+YUAlz3/GSwoB396/85CDmq750TiaRG3lKp4hvY7vIRp999TJQ5AMzl3158+d8 ZDnzFvjH+gY+fXooZRLqm4D//5q5wIlfnUh9aPp3rl90/Na8mppTrVvFWZJn2upKKM xPbBNGyAgLo1w== Received: from [17.230.165.240] (unknown [17.230.165.240]) by st43p00im-zteg10062001.me.com (Postfix) with ESMTPSA id 7F9596C0B60; Fri, 17 Jan 2020 18:08:08 +0000 (UTC) From: Carrick Bartle Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_660C8889-78C4-478D-9907-36C2423DA22E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.3\)) Date: Fri, 17 Jan 2020 10:08:02 -0800 In-Reply-To: Cc: IETF SecDispatch To: Mike Ounsworth References: X-Mailer: Apple Mail (2.3608.80.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-17_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=942 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2001170142 Archived-At: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:08:19 -0000 --Apple-Mail=_660C8889-78C4-478D-9907-36C2423DA22E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom what I've gathered from the mailing list discussion on this topic = (in particular, the lead time necessary for hardware), it strikes me = that there is sufficient reason for this work to advance. > On Jan 16, 2020, at 11:13 AM, Mike Ounsworth = wrote: >=20 > Following up on in-room discussions at 106, and the ensuing list = discussions, I'd like to ask for confirmation of the following points: >=20 > 1. There is enough interest in an obvious-and-straightforward = implementation of composite signatures to continue working on it? > 1a. The current draft for this is = draft-ounsworth-pq-composite-sigs-02 >=20 > 2. SecDispatch is assigning this back to LAMPS? > 2a. The current draft might not be the most = obvious-and-straightforward implementation; we're willing to simplify = until it's in-scope for LAMPS. >=20 > --- > Mike Ounsworth > Software Security Architect, Entrust Datacard >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --Apple-Mail=_660C8889-78C4-478D-9907-36C2423DA22E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =46r= om what I've gathered from the mailing list discussion on this topic (in = particular, the lead time necessary for hardware), it strikes me that = there is sufficient reason for this work to advance.


On Jan = 16, 2020, at 11:13 AM, Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com> wrote:

Following up on in-room discussions at 106, and the ensuing = list discussions, I'd like to ask for confirmation of the following = points:

1. There is enough interest in an = obvious-and-straightforward implementation of composite signatures to = continue working on it?
  1a. The current draft = for this is draft-ounsworth-pq-composite-sigs-02

2. SecDispatch is assigning this back to LAMPS?
=   2a. The current draft might not be the most = obvious-and-straightforward implementation; we're willing to simplify = until it's in-scope for LAMPS.

---
Mike Ounsworth
Software Security Architect, = Entrust Datacard

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

= --Apple-Mail=_660C8889-78C4-478D-9907-36C2423DA22E-- From nobody Fri Jan 17 10:16:03 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8A12007C for ; Fri, 17 Jan 2020 10:16:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j0CG-XbAMC4 for ; Fri, 17 Jan 2020 10:15:56 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF53120043 for ; Fri, 17 Jan 2020 10:15:56 -0800 (PST) IronPort-SDR: 9lsvcMyI/2kLghPLNzLRU/r2r4X2BV3VIf7fcP9K4459dIOgPrH7Ne3cPR39ZNXT/6YyLrFDau aSjZlOvzNJRA== X-IronPort-AV: E=Sophos;i="5.70,331,1574143200"; d="scan'208";a="7754814" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 17 Jan 2020 12:15:56 -0600 Received: from pmspex02.corporate.datacard.com (192.168.211.30) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jan 2020 12:15:55 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 17 Jan 2020 12:15:55 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jdn9iUdsKRf+qdGBlVw7nF7hcDHvAU/FxeGDbL85/B6IMUCJ7zsDPJyTkIh5diiZBhtHxrU7iiVJ0RhAIfTbUdyUUfKDZHiedbahRChiZsupXWWBHQiSv47ksjiey3ZOqiDcuM/4eQdAE14EoEwvC86M03bJv3KHt8f0wUTpDo8rfXPKkqRs6Gd6j/wi27HF5lGPqc3S73yNkXHE+QxSRoSWJ/LPZosgQJJP23+3f3MwDNXV/Nry5keLRNh0E1GYsmszqgsLwitfX4ibSN5cuB/sBa8h73hm6RKzD6mr7CR3mVKJUmcdv1oDXGvNvtRVvikjyYrFKt6x0SB2+RUpIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmlcVG6QFopnN83YVPFzyM9+DzxWD9E7gOjnE+iUCnk=; b=PrMCApxODrf/kJ/Er2l1wzX7/ahbbj67zDbVG9C+GKdtKzH27pGnfjGLfAICElQVPOUF+ZTSRerJ3Vl2t83UcbBvnJXIYGDtFPVKcHMyxc2qOiG2c8xdsXc+v5WxpuHtoLBpcuNu81RowRNp7jVerpvE8oJcPjopxvFnvFod97nEgyxqU8R0gQaPk6v5ls+6QxKN1T058sRubG/9veSJtr02mKdlIluGE0iVmygil3nBIzT2evbJwFe+POQJvdyxEtUkjv71HjC+Om6mJBieoGGe+kBsnBIG0fsI4RM0ssjj9pq9qx3hJL2XlZPew28gVPp62YBGR2iUnUrDNdhSNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GmlcVG6QFopnN83YVPFzyM9+DzxWD9E7gOjnE+iUCnk=; b=HsW8NE+VZQ5Q0uAdZWivP0nx2CTZbKYvy5QbBU/Tk0aj1E5xYtIDhAz9wdkLbVNokiwvJPft/n7EvVBbiGT4d/VJ/3Z9oZlRjEfLSQUwSCs4eIiUE8s6o1KSbZSMB6BESwdcbPRcQFAt4RfJ5Gqc4HjbuK2tdgkwUFuuXHlPiBw= Received: from BYAPR11MB3478.namprd11.prod.outlook.com (20.177.184.84) by BYAPR11MB3606.namprd11.prod.outlook.com (20.178.206.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Fri, 17 Jan 2020 18:15:53 +0000 Received: from BYAPR11MB3478.namprd11.prod.outlook.com ([fe80::21d5:97a8:95ea:3182]) by BYAPR11MB3478.namprd11.prod.outlook.com ([fe80::21d5:97a8:95ea:3182%7]) with mapi id 15.20.2623.017; Fri, 17 Jan 2020 18:15:53 +0000 From: John Gray To: Stephen Farrell , "Markku-Juhani O. Saarinen" , IETF SecDispatch CC: Daniel Van Geest , Mike Ounsworth Thread-Topic: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS? Thread-Index: AdXMlh5Ba3U4rdZGTG6zfD9kbyUHDgADO5QAAASPDwAAHnjCAAAAaCmAAABGooAACxnO0A== Date: Fri, 17 Jan 2020 18:15:53 +0000 Message-ID: References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> In-Reply-To: <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=John.Gray@entrustdatacard.com; x-originating-ip: [216.191.252.67] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23036bd0-2b1c-44a1-be57-08d79b794a35 x-ms-traffictypediagnostic: BYAPR11MB3606: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39850400004)(136003)(366004)(189003)(199004)(478600001)(966005)(54906003)(316002)(296002)(110136005)(2906002)(86362001)(71200400001)(33656002)(9686003)(55016002)(76116006)(81156014)(81166006)(66446008)(52536014)(66556008)(186003)(64756008)(8676002)(4326008)(8936002)(66946007)(66476007)(26005)(6506007)(5660300002)(53546011)(7696005)(107886003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR11MB3606; H:BYAPR11MB3478.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nAplrqII0suafXchfNkNbtsz8hBfMbGqvel9xDck8sXvWRffTRPAyuie18YJyLi0RkvtLJqd9VswuIzb7o4aUawLoamgT0qEdPzJAKvumvoYGUsrZ9KQrGLu+/MJ2I4dl+nEmM81WD7F9JNyzV7Q6IOEm1a9j65HHdJf4Il2vTksyINXCFpnpjD3GnjDt5InEsirFil/ZL2cD1uMoP8HF7RpW3IreEl8wCJZlwe9YoUMjn2WwwAFCIu1kurluO7PNS6mr09JWqYCVgYiSuOT0WJZLpcsQhF/i4deM7lBOD2JVx8y0eFyXv6P1hHXuSLbUvZidziEjsmmUh7BwqT5JFkM+mdmo9CIi47OaNf94BDVGfoMNaGUsRzy3xl5OYMdy6hwrVuG/+7XqUT3umlFnP2jj1pSRizMy2pWyBwfVH/k8WVpNB0cM1nGBcNEe2Fz7b7MltrkqH+veKb+XpBDyPxnlL1esTfehIIKtBrEVFA= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 23036bd0-2b1c-44a1-be57-08d79b794a35 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 18:15:53.2369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gwK1dMDouhkPzhU3CVlmlVcJa/BHs/+E9MfvDOBOaC2bhGkdSpEfZlTaYUfWPiatGmO6lNAPcBJW3TiXI4cwiADSUcRb5szBruJ0yMzCoWs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3606 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:16:01 -0000 SGkgU3RlcGhlbiwNCg0KVGhlIHJlYXNvbiB3aHkgd2UgYXJlIHB1dHRpbmcgdG9nZXRoZXIgdGhp cyBjb21wb3NpdGUgc3RhbmRhcmQgaXMgYmVjYXVzZSB3ZSBiZWxpZXZlIHdlIGFyZSBpbiB0aGlz IHBvc2l0aW9uIHRvZGF5LiAgIElmIE5JU1QgIGRlY2lkZXMgbm8gUm91bmQgMyBpcyBuZWVkZWQs IHRoZW4gd2Ugd2lsbCBrbm93IHRoZSBQUSB3aW5uZXJzIGJ5IEp1bmUgb2YgdGhpcyB5ZWFyLiAg IEV2ZW4gaWYgdGhlcmUgaXMgYSBSb3VuZCAzLCBhbmQgbm8gZmluYWwgc2V0IG9mIFBRIGFsZ29y aXRobXMgaXMgZGVjbGFyZWQgdW50aWwgMjAyMSBvciAyMDIyLCB3ZSB3YW50IHRvIGhhdmUgYSBo eWJyaWQgc3RhbmRhcmQgcmVhZHkgZm9yIHVzIHVzZS4gIFdlIHdpbGwgbmVlZCB0byBpbXBsZW1l bnQsIHRlc3QsIGFuZCBpbnRlcm9wIGFuZCBhbGwgdGhlc2UgdGhpbmdzIHRha2UgdGltZSBhbmQg aGF2ZSB0byBiZSBkb25lIGFmdGVyIHRoZXJlIGlzIGEgc3RhbmRhcmQuICBJZiB3ZSB3YWl0IHRv byBsb25nLCBpdCB3aWxsIGJlIGEgZnJlZSBmb3IgYWxsLiAgIA0KDQpUaGVyZSBhcmUgYWxyZWFk eSBhIHNtYWxsIGhhbmRmdWwgb2Ygc3RhYmxlIFBRIGFsZ29yaXRobXMgYXZhaWxhYmxlIHRvIHVz ZSB0b2RheS4gICBTZWUgUkZDIDgzOTEgKFhNU1MpIGFuZCBSRkMgODU1NCAoTE1TKSwgc28gdXNp bmcgYSBoeWJyaWQgUlNBIG9yIEVDIHdpdGggWE1TUyBvciBMTVMgaW4gYSBjb21wb3NpdGUgZm9y bSBpcyBhbHJlYWR5IHZpYWJsZS4gIFRoZSBjaG9pY2VzIGFyZSBkZWZpbml0ZWx5IGZldyBhdCB0 aGlzIG1vbWVudCwgYnV0IHRoZXJlIGFyZSB2aWFibGUgdXNlLWNhc2VzLiAgIFdlIHdhbnQgdG8g Z2l2ZSBvdXIgY3VzdG9tZXJzIHBlYWNlIG9mIG1pbmQgYW5kIHRyYW5zaXRpb24gdG8gYSBwb3N0 IHF1YW50dW0gd29ybGQuICBUaGlzIHN0YW5kYXJkIHdpbGwgYWRkcmVzcyBjdXN0b21lciBhbnhp ZXR5IGFuZCBicmlkZ2VzIHRoZSBnYXAgdG8gYSBzdGFibGUgcG9zdCBxdWFudHVtIHdvcmxkLiAg IEl0IGFkZHJlc3NlcyB0aGUgcXVhbnR1bSB0aHJlYXQgdmVyc2VzIGFsZ29yaXRobSBzY3J1dGlu eS4gIA0KDQpDaGVlcnMsDQoNCkpvaG4gR3JheQ0KU29mdHdhcmUgQXJjaGl0ZWN0LCBFbnRydXN0 IERhdGFjYXJkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTZWNkaXNwYXRj aCBbbWFpbHRvOnNlY2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVw aGVuIEZhcnJlbGwNClNlbnQ6IEZyaWRheSwgSmFudWFyeSAxNywgMjAyMCA3OjMwIEFNDQpUbzog TWFya2t1LUp1aGFuaSBPLiBTYWFyaW5lbiA8bWpvc0BwcXNoaWVsZC5jb20+DQpDYzogRGFuaWVs IFZhbiBHZWVzdCA8RGFuaWVsLlZhbkdlZXN0QGlzYXJhLmNvbT47IElFVEYgU2VjRGlzcGF0Y2gg PHNlY2Rpc3BhdGNoQGlldGYub3JnPjsgTWlrZSBPdW5zd29ydGggPE1pa2UuT3Vuc3dvcnRoQGVu dHJ1c3RkYXRhY2FyZC5jb20+DQpTdWJqZWN0OiBbRVhURVJOQUxdUmU6IFtTZWNkaXNwYXRjaF0g Q2FuIENvbXBvc2l0ZSBzaWdzIG1vdmUgYmFjayB0byBMQU1QUz8NCg0KDQoNCk9uIDE3LzAxLzIw MjAgMTI6MjIsIE1hcmtrdS1KdWhhbmkgTy4gU2FhcmluZW4gd3JvdGU6DQo+IE9uIEZyaSwgSmFu IDE3LCAyMDIwIGF0IDEyOjExIFBNIFN0ZXBoZW4gRmFycmVsbCANCj4gPHN0ZXBoZW4uZmFycmVs bEBjcy50Y2QuaWU+DQo+IHdyb3RlOg0KPiANCj4+DQo+IE15IGNvbmNsdXNpb24gaXMgdGhhdCB0 aGlzIHN0dWZmIGNvdWxkIG9ubHkgcmVhbGx5IGJlIHVzZWZ1bA0KPj4gZW5vdWdoIHRvIGp1c3Rp ZnkgdGhlIGNvc3RzIGlmIHdlIGhhdmUgUFEgc2lnbmF0dXJlIHNjaGVtZXMgdGhhdCBhcmUgDQo+ PiBjb25zaWRlcmVkIHN0YWJsZSBlbm91Z2ggdG8gZGVwbG95IGJ1dCB3aGVyZSB3ZSBkb24ndCB5 ZXQgZnVsbHkgdHJ1c3QgDQo+PiB0aGUgYWxnb3JpdGhtcyB0byB0aGUgcG9pbnQgd2hlcmUgd2Un ZCBiZSBoYXBweSB0byBkZXBlbmQgc29sZWx5IG9uIA0KPj4gdGhvc2UgbmV3IGFsZ29yaXRobXMu DQo+IA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHN1cHBvcnQuIFRoYXQgaXMgZXhhY3RseSB3aGVy ZSB3ZSBhcmUNCg0KSSBob3BlIGl0J3MgY2xlYXIgSSBkaXNhZ3JlZSB3aXRoIHlvdSAtIElNTyB0 aGUgY29uZGl0aW9ucyBhYm92ZSBhcmUgbm90IHNhdGlzZmllZCB0b2RheSBhbmQgSSBkbyBub3Qg c3VwcG9ydCBhZG9wdGluZyBzdWNoIHdvcmsgYXQgdGhpcyB0aW1lLiBXZXJlIEkgdG8gZ3Vlc3Mg YW5kIGJlIG9wdGltaXN0aWMgaXQgbWlnaHQgYmUgd29ydGggcmUtY29uc2lkZXJpbmcgdGhlIHRv cGljIGluIGEgeWVhciBvciBzby4NCg0KUy4NCg0KPiBhbmQgd2hhdCB0aGUgc3RhdGVkDQo+IHB1 cnBvc2Ugb2YgZHJhZnQtb3Vuc3dvcnRoLXBxLWNvbXBvc2l0ZS1zaWdzLTAyIGlzLg0KPiANCj4g Q2hlZXJzLA0KPiAtIG1hcmtrdQ0KPiANCj4gRHIuIE1hcmtrdS1KdWhhbmkgTy4gU2FhcmluZW4g PG1qb3NAcHFzaGllbGQuY29tPiBQUVNoaWVsZCwgT3hmb3JkIFVLLg0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNlY2Rpc3BhdGNo IG1haWxpbmcgbGlzdA0KPiBTZWNkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQo+IA0K From nobody Fri Jan 17 10:33:10 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9033120074 for ; Fri, 17 Jan 2020 10:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSsHHkFwl7Ct for ; Fri, 17 Jan 2020 10:33:04 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E494120025 for ; Fri, 17 Jan 2020 10:33:04 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id m26so27389387ljc.13 for ; Fri, 17 Jan 2020 10:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=0BRqOzN+4Hik3rkOnkLaP2hJjqB+B/V1X4PQPN8Jo+A=; b=Cfat5wNfJKH2OSYsfDehzacw3qOToNTQBHVueQFmBlvJNl2NY/RMADFaMDdHcRCZ3a oJGef1Ei9/SD1ozpM2zUxwWdhcoYndOdQav5V2NVIFx3RIjzlwMw9JukNoeprg5fNoix iFDJfpVojhk+Q50irtuYBoai8cI3ckqRvLTnXhW+91fSlt5ASITgSXvKDUfQAOz7v1MP OWHrZaTjTVZnWFU/8JvQ+1Y/dAl9CtZwPELE4VIb+WjGgcQJcnS4+HsyKDJkdtkWD2m+ JO/XN4zIGr8tD7i6cS+y3zLBVENUJU7hau8iYkL/XlgyRXBOI+3eW3ysBL1RNhWe4mTC OzUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=0BRqOzN+4Hik3rkOnkLaP2hJjqB+B/V1X4PQPN8Jo+A=; b=rIRh9ilBKSjoFDV/omlJs/2e1VplmLZxqWbKNfoUqY7XAfWbqwLAUb3boc9w4155S3 quJLNyXsmnuE0R3dEsRPTRb5a6f31LfTRv8PPAG+b52adYYVVCx3pFHbLsb1Vh6KV2EK BzOngYWWmOrrha2TQmOdwFWUH3A0oQMkBMU+wqsV7qd0G0uLFR5me96C46UHRLJCJXws Mn/SH6PJ/c9J72C9+sGbU5jKPiPXetlfqwoHDqN35TgrX5L1zNK4rgIWIRxFArqHElTq UCG3enPer+6Gh0JbefOjLtHq4p8OpuULq3Pixd20sPQlUIi4sc40s8xtmKO+2kE3ryw0 UE7Q== X-Gm-Message-State: APjAAAW7TyW6MQ4XZDuwafs1N/yxLZq6FtgFv/F7ZZqad9FP5zSxMRzR ItfeU/s1a0RV5h9al3nTafk= X-Google-Smtp-Source: APXvYqxEuMSc21YJrSUympLlOT8AJLKl8Zyu0sufGCgIDLNBZMp6mQFivb5d+HytCpTU30EwXg5jIA== X-Received: by 2002:a2e:818e:: with SMTP id e14mr6379587ljg.2.1579285982471; Fri, 17 Jan 2020 10:33:02 -0800 (PST) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id c189sm12565402lfg.75.2020.01.17.10.33.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 17 Jan 2020 10:33:01 -0800 (PST) From: "Valery Smyslov" To: "'Stephen Farrell'" , "'Markku-Juhani O. Saarinen'" Cc: "'Daniel Van Geest'" , "'IETF SecDispatch'" , "'Mike Ounsworth'" References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> In-Reply-To: <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> Date: Fri, 17 Jan 2020 21:32:57 +0300 Message-ID: <006401d5cd64$8a871570$9f954050$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKORapB8Wx4IiRlWtp9XVJpPbCs2ADqO76pAmH4y4wCLkqvBwI2wqzjAjhBkSumLux6EA== Content-Language: ru Archived-At: Subject: Re: [Secdispatch] Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:33:10 -0000 Hi Stephen, > > My conclusion is that this stuff could only really be useful > >> enough to justify the costs if we have PQ signature schemes that = are > >> considered stable enough to deploy but where we don't yet fully = trust > >> the algorithms to the point where we'd be happy to depend solely on > >> those new algorithms. > > > > > > Thanks for your support. That is exactly where we are >=20 > I hope it's clear I disagree with you - IMO the conditions above are = not > satisfied today and I do not support adopting such work at this time. = Were I > to guess and be optimistic it might be worth re-considering the topic = in a > year or so. Given the usual IETF performance, a year is a term just to launch a real = work and realize where to go. So, I think we should start doing it now to = have plenty of time and not to be in a hurry later. Regards, Valery. > S. >=20 > > and what the stated > > purpose of draft-ounsworth-pq-composite-sigs-02 is. > > > > Cheers, > > - markku > > > > Dr. Markku-Juhani O. Saarinen PQShield, Oxford > UK. > > > > > > _______________________________________________ > > Secdispatch mailing list > > Secdispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/secdispatch > > From nobody Fri Jan 17 12:06:26 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BE51200CD for ; Fri, 17 Jan 2020 12:06:25 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 J6Z-ujvX8UpT for ; Fri, 17 Jan 2020 12:06:19 -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 DA76E1200A4 for ; Fri, 17 Jan 2020 12:06:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 78D32BDCF; Fri, 17 Jan 2020 20:06:16 +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 HFbYvBKnRdRl; Fri, 17 Jan 2020 20:06:14 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 739F1BE20; Fri, 17 Jan 2020 20:06:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579291574; bh=6//nUxCFstxHkPN26GC7ntzdPsRQXVr3cHvs48+VoPc=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=irwvNKn8sVwftvfcOzy4K1Uktn3OeU3KCZzAgHwCZuUfXk9UxoixBMqy7/d+o+Lyh UDe5W4zoxe+bWA76ykO5O+p/gMoxo1osDqxWoiUnaVYj0Ou4Ha5h4rym02/WAfBdfA mcn5o0rMJxZ4JGxtfTe5DwlAwoxnsfvWNwnXMLRc= To: John Gray , "Markku-Juhani O. Saarinen" , IETF SecDispatch Cc: Daniel Van Geest , Mike Ounsworth References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> From: Stephen Farrell 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: <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> Date: Fri, 17 Jan 2020 20:06:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1cAczJlPQIfn6r0kHf1gXMaVuJCHeV5Dn" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 20:06:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1cAczJlPQIfn6r0kHf1gXMaVuJCHeV5Dn Content-Type: multipart/mixed; boundary="EHEr8yjBG7oAT1wrGYEeYCiDWZDWjRs6b"; protected-headers="v1" From: Stephen Farrell To: John Gray , "Markku-Juhani O. Saarinen" , IETF SecDispatch Cc: Daniel Van Geest , Mike Ounsworth Message-ID: <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> Subject: Re: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS? References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> In-Reply-To: --EHEr8yjBG7oAT1wrGYEeYCiDWZDWjRs6b Content-Type: multipart/mixed; boundary="------------EF474E7FF615DBD91E4D4454" Content-Language: en-US This is a multi-part message in MIME format. --------------EF474E7FF615DBD91E4D4454 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Replying to a few mails at once, but ISTM this is starting to get repetitive. On 17/01/2020 18:15, John Gray wrote: > Hi Stephen, >=20 > The reason why we are putting together this composite standard is=20 > because we believe we are in this position today. If NIST decides=20 > no Round 3 is needed, then we will know the PQ winners by June of=20 > this year. Even if there is a Round 3, and no final set of PQ=20 > algorithms is declared until 2021 or 2022, we want to have a hybrid=20 > standard ready for us use. We will need to implement, test, and=20 > interop and all these things take time and have to be done after=20 > there is a standard. If we wait too long, it will be a free for=20 > all. Right now there are too many algorithms to believe that we'd have other than a free-for-all as those pushing one or another try get their thing adopted. I'd also note that NIST has a history or defining new parameterisations after algorithm selection, so wouldn't be surprised if that happened here too. I'd prefer we wait and see what results from the NIST thing rather adopt work now in the IETF. If people want to do work ahead of NIST then that's of course fine, but adopting such work in the IETF is asking us all to do work on this now, and I think that's both risky and wasteful. >=20 > There are already a small handful of stable PQ algorithms available=20 > to use today. See RFC 8391 (XMSS) and RFC 8554 (LMS), so using a=20 > hybrid RSA or EC with XMSS or LMS in a composite form is already=20 > viable. The choices are definitely few at this moment, but there > are viable use-cases. Stateful signature schemes such as those are not suited for use in X.509 IMO, as was already raised on the list. (And someone earlier claimed they wouldn't work for their use-cases, so I'm confused as to whether the proponents here do or don't want to include stateful signature schemes.) On 17/01/2020 17:54, Mike Ounsworth wrote: > Cool. In the meantime, we plan to keep working on the outstanding=20 > TODO decision points in the draft as more vendors approach us for=20 > interop testing. :-) I've no objection to people working on stuff. I am opposed to the IETF prematurely adopting work in this space though. On 17/01/2020 18:08, Carrick Bartle wrote: > From what I've gathered from the mailing list discussion on this=20 > topic (in particular, the lead time necessary for hardware), it=20 > strikes me that there is sufficient reason for this work to advance. My experience in the IETF is that ill-defined and less well understood work takes longest. I think this matches that at the moment. I'd suggest the proponents might be better spending time on developing their work by implementing it in open-source generic PKI libraries and applications so that they can produce some non arm-waving evidence as to what this does or doesn't break. (IMO, it'll turn out to break a lot and change many lines of code, but who knows, I may be wrong.) On 17/01/2020 18:32, Valery Smyslov wrote: > Given the usual IETF performance, a year is a term just to launch a=20 > real work and realize where to go. So, I think we should start doing=20 > it now to have plenty of time and not to be in a hurry later. See above as to how to speed things up more effectively. Additionally, the idea that waiting a year or so means someone would have to "be in a hurry" seems questionable to me. Cheers, S. --------------EF474E7FF615DBD91E4D4454 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------EF474E7FF615DBD91E4D4454-- --EHEr8yjBG7oAT1wrGYEeYCiDWZDWjRs6b-- --1cAczJlPQIfn6r0kHf1gXMaVuJCHeV5Dn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4iE7UACgkQWrL68XsX K+oBoA/+NAgdE5UWc8LoXi9nueuvwhtK1ct1F6vZptHiLYauwNYRNYNIO2jYi2+r XP69MW5Xrzr4NHn875a5eCp8Zgx0YlIIcfI/pS/PgbbZ6L8WQ3DCv7B7E2YXR/EP 4weEkT7Qmm8NPhF+wa3jCptVZ9XoTsMJZOZnv2FwMjYX3dNdpL0H5sj2bLvOAddo sCs/YqyckgW5+9XVaKUWOjIN4GAJIxwGPGgihEdSvdkMQfTzp/soVHK2Kx96989E 2tYAnDfN0yTxxQqR/qS/qRTWKlNGBjN+CqO1zbnKEv3ZctLkUA0LEzMBhmjL6uPC 2UBSEYwnAGO+LEYAEiIn15Ow0qd4YOWF420558/QrzTRCiRw8QBEFkWbmJEagcgD kVmFaUUIXXVxGDfml1Ei84HXgDy3nhq6H0pT6NrcK+xEEjhiuS1R74SRXxDXdmj7 jYpRcmVuICO1j5GRXgBjZj+C6A+F7uOCVLcrV4gD4EsitaYnyEM9DocAjq5vWc2J qldswJ/P/MiyaO9LR7QBQRb+shK+tnmoPqjDO2udhklx1Y3OXi0UVZJ08Rz7eA7D WNT7d09OBWOs484HBtT+ObilxuHXN0i4AD1ciRJYfBnY4nMT9SVlI8c7ULvFR3P5 3bnzd1edYepraoVAGGikhZubERqoWFCW2fB7MatAqHsEPV3sA9w= =C29+ -----END PGP SIGNATURE----- --1cAczJlPQIfn6r0kHf1gXMaVuJCHeV5Dn-- From nobody Fri Jan 17 12:43:28 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E381200FB for ; Fri, 17 Jan 2020 12:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 lVRH-SDpMIk5 for ; Fri, 17 Jan 2020 12:43:24 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6201200F3 for ; Fri, 17 Jan 2020 12:43:23 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id m26so27730234ljc.13 for ; Fri, 17 Jan 2020 12:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BEKZOIx4AXNTOWW97/ua8nO+/hSteLB/EAbk+cmXfBU=; b=WEYU68sIOjxx0m2RA+MlhE78xrCPjSMH21epO4I9omb46Y1+C39tG6CtcvDMBbyoYh wNVTsbnWRP/WkN4bN+c0MX41YmElHK+arUJwmEeYub0TLc2WFkZCFadEsWvbKC2PZMuA PpeHCSyGYwAQ8rugJV2Tfr+Z56vEonmLeuwARy0tc3IVx2b/obWmJO/0ZAVYgVTnGvd1 8ANyJI/IBylNLmAJy+xA5d7B6Dd/TEHbSItCnhKDoTH1tG+XLja+r2bOVpZnSYLucyWV U0oaj3WNGY7FGz92HwRYKf8HOTx6ghzvuNZIKN01puDdrpA5rdVCC7YkcJswyZJSHpxd QJ7g== 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=BEKZOIx4AXNTOWW97/ua8nO+/hSteLB/EAbk+cmXfBU=; b=j/j9NGaWL2J02gdFx5aPs+Ni5Y0+oBDiw3TVax8/d3ElNCylU8kM+Y6Z4Ddp0+Sm5w Ikoyy8wIok2WLeAIhaa2WBzSdXZUv94lx02DoqdxlCl0nv+fjH430ADZqncXIuQ8VP0/ MOI1c00CRaNWxHDvLYkD3dJ5D950dT2hg2l574Mro23qb5lmk4caoyLlozsWXqu1/Gvx ByRgDlm9GnOFX2IruC5LLjA2mjTww3kUhZiNUaWrS7dlDVQkKXMsvStIDgEoT1BPzHcP NzHQxozQSh8VW5FtYzN78+gwLnf5Maj6K92+MgmrKd/iyPb2CfFXwnypcFgwSrnDj1bA 1JTQ== X-Gm-Message-State: APjAAAUtXV1CYk4T1KKaX673UuL+fR3RAJ77xuWD8XQ2Ig6jK5WvOl4H /pkvYLeCJOLP+eIKnrI7mo5r6/LNNpl7nSQ6VRj0xXs0AP8vWihilsXnBfQIaXNMgiZ1pk8zoFx zOMLgPG4U3REtt5moBrkafw== X-Google-Smtp-Source: APXvYqymQWziLXd91hPvqIu8c7wVtloY5sq5MuEQ3dibuU9WoxFwVfapyqvnctNRTLKL4OVEBcQk1Np55EdV2pbtfUE= X-Received: by 2002:a2e:9687:: with SMTP id q7mr6494577lji.232.1579293802072; Fri, 17 Jan 2020 12:43:22 -0800 (PST) MIME-Version: 1.0 References: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> In-Reply-To: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> From: Brian Campbell Date: Fri, 17 Jan 2020 13:42:55 -0700 Message-ID: To: Francesca Palombini Cc: "saag@ietf.org" , "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000011a392059c5bfe4e" Archived-At: Subject: Re: [Secdispatch] SECDISPATCH WG Summary from IETF 106 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 20:43:27 -0000 --00000000000011a392059c5bfe4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies folks, I'm responsible for the rushed and awkward presentation about reverse proxies and TLS client certificates at the very end of the SECDISPATCH session in Singapore, which is mentioned below with "no draft yet--> needs draft". It took me a little while to get through the work but I'm happy to share that there is now an actual draft available. Here it is in the fancy new HTML format: https://www.ietf.org/id/draft-bdc-something-something-certificate-01.html as well as the good ol status page: https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ On Tue, Nov 19, 2019 at 9:34 PM Francesca Palombini wrote: > The SECDISPATCH WG met on Tuesday November 19. The agenda items were > dispatched as follows: > > > > (1) Problem statement for post-quantum multi-algorithm PKI (Max Pala) > > drafts: https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement= / > > > https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/ > > --> dispatch to LAMPS WG (confirm on mailing list) > > > > (2) OCSPv2 - Improving OCSP Responses (Max Pala) > > LAMPS & PKIX discussions: > > Draft: https://tools.ietf.org/html/draft-pala-ocspv2-00 > > --> create a BoF for small focused WG > > > > (3) Privacy Pass Protocol (Nick Sullivan) > > drafts: https://datatracker.ietf.org/doc/draft-privacy-pass/ > > --> work on charter text then BoF for small focused WG > > > > (4) HTTP Request signing (Justin Richer) > > draft: https://tools.ietf.org/html/draft-cavage-http-signatures > > --> dispatched to HTTPBIS WG > > > > (5) Communication Network Perspective on Malware Lifecycle (Joachim Fabin= i) > > draft: > https://datatracker.ietf.org/doc/draft-fabini-smart-malware-lifecycle/ > > --> check the IAB project (talk to Ted) > > > > (6) Securing protocols between proxies and backend (HTTP?) servers (Brian > Campbell) > > draft: Looking for support/contributors, no draft yet > > --> needs draft > > > > Detailed minutes will be coming in the next couple of weeks. > > > > Thanks, > Francesca > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000011a392059c5bfe4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies folks, I'm responsible for the rushed = and awkward presentation about reverse proxies and TLS client certificates = at the very end of the SECDISPATCH session in Singapore, which is mentioned= below with "no draft yet--> needs draft". It took me a little= while to get through the work but I'm happy to share that there is now= an actual draft available. Here it is in the fancy new HTML format: https://www.ietf.org/id/draft-bdc-something-somethin= g-certificate-01.html as well as the good ol status page: https://datatracker.ietf.org/doc/draft-bdc-something-some= thing-certificate/


On Tue, Nov 19, 2019 at 9:3= 4 PM Francesca Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.org> wrote:

The SECDISPATCH WG me= t on Tuesday November 19.=C2=A0 The agenda items were dispatched as follows= :

=C2=A0<= /span>

(1) Problem statement= for post-quantum multi-algorithm PKI (Max Pala)

drafts:= =C2=A0 https://datatracker.ietf.org/doc/draft-pq-pkix-= problem-statement/

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracke= r.ietf.org/doc/draft-ounsworth-pq-composite-sigs/<= /p>

--> dispatch to LAMPS WG (confirm on mailin= g list)

=C2=A0<= /span>

(2) OCSPv2 - Improvin= g OCSP Responses (Max Pala)

LAMPS & PKIX disc= ussions:

Draft:=C2=A0 htt= ps://tools.ietf.org/html/draft-pala-ocspv2-00

--> create a BoF f= or small focused WG

=C2=A0<= /span>

(3) Priva= cy Pass Protocol (Nick Sullivan)

drafts: <= a href=3D"https://datatracker.ietf.org/doc/draft-privacy-pass/" target=3D"_= blank">https://datatracker.ietf.org/doc/draft-privacy-pass/

--> work on charte= r text then BoF for small focused WG

=C2=A0<= /span>

(4) HTTP Request sign= ing (Justin Richer)

draft: https://tools.ietf.org/html/draft-cavage-http-signatures=

--> dispatched to = HTTPBIS WG

=C2=A0<= /span>

(5) Communication Net= work Perspective on Malware Lifecycle (Joachim Fabini)=

draft: https://datatracker.ietf.org/doc/draft-fabini-smart= -malware-lifecycle/

--> check the IAB = project (talk to Ted)

=C2=A0<= /span>

(6) Securing protocol= s between proxies and backend (HTTP?) servers (Brian Campbell)

draft: Looking for su= pport/contributors, no draft yet

--> needs draft=

=C2=A0<= /span>

Detailed minutes will= be coming in the next couple of weeks.

=C2=A0<= /span>

Thanks,
Francesca


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000011a392059c5bfe4e-- From nobody Fri Jan 17 14:17:32 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1380D120836 for ; Fri, 17 Jan 2020 14:17:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_rw9DQZiNbv for ; Fri, 17 Jan 2020 14:17:24 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7DD1120026 for ; Fri, 17 Jan 2020 14:17:24 -0800 (PST) IronPort-SDR: CPlWrUkOHkZYGw1w/RgDGufWxH0ap1k2rMB+67JX+BQoxvbBydrFCXqnMmmYKyVvwaYK2X6XZ7 d0gJOJYLNFXg== X-IronPort-AV: E=Sophos;i="5.70,331,1574143200"; d="scan'208";a="7765323" Received: from pmspex02.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.30]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 17 Jan 2020 16:17:24 -0600 Received: from PMSPEX03.corporate.datacard.com (192.168.211.50) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jan 2020 16:17:23 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (172.28.1.8) by PMSPEX03.corporate.datacard.com (192.168.211.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 17 Jan 2020 16:17:23 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I3ax3zTD5KV2d16weQ2AHfxuPbsZajRV6Hj6o1+dT/oXI++gIocJcaXh/sI9qNMiaDewR5I7FDanJTtL2t8nS8YulqnnOZJawBBpuOTKOEMMqd+n3gVxRbapvrNNLSsw818q5oVKoWmsynQb1nOoS7oSs9oBEYE4mFQz5qwo4TVfoXnHTyLjKFDg+rBoYRb29RKslLLftcfLElBLlvV7c2P1YzdcPgrTvwJGNyh/LVh0qFVL0cIxAHFcJCNqeaCecpwO9yHBJ/0gsqvlTL97S8PTTovsjPiuXACFCRKZpCdqt8mL9+9mJEMfAGfEJbgSqzr4I0GwI+vGE5FeYHTDdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=99eMq+2A8NURoKpsUzQh8HxyEiM9Lh6D5ZQNcEQLIEk=; b=MR/c9oLwvli7zXdYJHqCXBSeRCgrHN5mq4XBZp2u70CgptoTB8o5fgIvMYdBRyabmO8NxFavJJA1/8SgZrFYwWALvW+Ye19WKFPTFgYDfyF5LRXO7GhuENBsVQaJp8QLfOZe8DI2qNfXHPxzNYyOm+zCLJFvx4YTNQLHMFCgym6B6KLQjSHs53M0T0KxF+tq/IOzjjjajE6c8DiVBkWv9hvgV2Mm7OOlugdAHEHUTsmSVCt6YMUGw28vo9Tfo7CAlrYIAMOSzbIqkcirA7eNKU63/ynozkKGFUqtx/ORyGOpcI3tX2sQMF01dyZ0uRgAtDOgzTOQhOjS0210qIf+Wg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=99eMq+2A8NURoKpsUzQh8HxyEiM9Lh6D5ZQNcEQLIEk=; b=wNXLJs8thU4EXiyfBPccH6AWBWtwXUxSiUF+6U+ZWgpJWYCd3tnHvA6ISmd/qR02f7v50RaPTKXwbOZs3nqv4On3jMVgGYXh16jycRpkflhVPGTv6Jpto0zMPDRW7q+IUrTaUaCzFCt0D+tetLUAPtzWNaqAxLo0DaU5mmttm7A= Received: from DM6PR11MB3883.namprd11.prod.outlook.com (10.255.61.32) by DM6PR11MB4281.namprd11.prod.outlook.com (52.132.251.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Fri, 17 Jan 2020 22:17:22 +0000 Received: from DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392]) by DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392%6]) with mapi id 15.20.2644.023; Fri, 17 Jan 2020 22:17:22 +0000 From: Mike Ounsworth To: Stephen Farrell , John Gray , "Markku-Juhani O. Saarinen" , IETF SecDispatch CC: Daniel Van Geest Thread-Topic: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS? Thread-Index: AQHVzS8z4XsT5+vb5UScUzn4/98hV6fuxzqAgAACNYCAAGCBgIAAHtSAgAAdMFA= Date: Fri, 17 Jan 2020 22:17:21 +0000 Message-ID: References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> In-Reply-To: <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [70.76.144.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 584aa25a-d4c2-456f-14d2-08d79b9b0610 x-ms-traffictypediagnostic: DM6PR11MB4281: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(136003)(39860400002)(346002)(199004)(189003)(71200400001)(55016002)(26005)(186003)(8936002)(8676002)(110136005)(4326008)(45080400002)(7696005)(33656002)(66446008)(9686003)(296002)(81156014)(66476007)(66556008)(64756008)(81166006)(5660300002)(478600001)(2906002)(86362001)(76116006)(53546011)(6506007)(52536014)(66946007)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB4281; H:DM6PR11MB3883.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PyvpWR7+UlTOkyrxUHHfY1HQUF5vdnorWwGoij8NFzgGrdGJc1PuD9vXuqwvD0kcmerdJ1Uasg3oCRg505IUG59mC7VP6NdaanYMuvdGfOtdIIiJOKenYAeZ+FhVOux8qaakwml0zqap1v3OPnOwc0Ecuwm+bxcSjMSO+E/OyHjyQn8GNSXwcCkUmOGo+2kA8wFDHZHa1GVcrfabS9qqax2CeFdwdaTO5oo8eqGcMQ+aRbvIzNHThVntEftAuMWsRoTni7oOI7q+DemV3Pi9fOpdFHJO3GVcYskOh6zv0pMZAIA4QEQPMSsF5RYXfNMKf4ICJsKW0eNDTkfKEYeE4T9qRZwZE/ZvJDl4YmzWZinOk7IFdlc7zZQJECvkLKTwjgANZ19I2KayNutmefvtO0X19zqk8vVhT2u+ygJVjKUbl1EA++mrR2G5WQQ1XmcV Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 584aa25a-d4c2-456f-14d2-08d79b9b0610 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 22:17:21.8348 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lwL5IAHZFVrCAJ9cx5YgE6ZehwFYRYOFhEVUyHc55wFp02V/IcKeY0UVVBAeaIpdboZdcMlgV0Lb1N3x3oJIedsZohQWobMUHlZTZ8Sm1rjOLGz3qaRLOfhLU6Wy2DY7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4281 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:17:30 -0000 SGkgU3RlcGhlbiwNCg0KV2UgbWF5IGhhdmUgYSBtaXN1bmRlcnN0YW5kaW5nIGFib3V0IHdoYXQg ZHJhZnQtb3Vuc3dvcnRoLXBxLWNvbXBvc2l0ZS1zaWdzIGlzIHRyeWluZyB0byBhY2NvbXBsaXNo LiANCg0KRHJhZnQtb3Vuc3dvcnRoLXBxLWNvbXBvc2l0ZS1zaWdzIGRlZmluZXMgQVNOLjEgc3Ry dWN0dXJlcyBmb3IgY2FycnlpbmcgbXVsdGlwbGUgU3ViamVjdFB1YmxpY0tleUluZm8sIEFsZ29y aXRobUlkZW50aWZpZXIsIGFuZCBCSVQgU1RSSU5HIChzaWduYXR1cmUgdmFsdWVzKSwgaW4gYSB3 YXkgdGhhdCB3aWxsIGJlIGRyb3AtaW4gZm9yIFBLSVgtbGlrZSBwcm90b2NvbHMuDQoNCllvdSBr ZWVwIG1lbnRpb25pbmcgcGFyYW1ldGVyIHNldHMgYW5kICJ3aGF0IGlmIHRoZXkgY2hhbmdlPyIu IEkgcmVhbGx5IGRvbid0IHNlZSB3aHkgdGhhdCdzIHJlbGV2YW50LiBEcmFmdC1vdW5zd29ydGgt cHEtY29tcG9zaXRlLXNpZ3MgaXMgYWxnb3JpdGhtLWFnbm9zdGljOyBvcnRob2dvbmFsIHRvIHRo ZSBjaG9pY2Ugb2YgYWxnb3JpdGhtcyBieSBOSVNUIG9yIHRoZWlyIGVuY29kaW5ncy4gDQoNCklm IGFueXRoaW5nLCBJIHNlZSB5b3VyIGFyZ3VtZW50IGJlaW5nIGluIHN1cHBvcnQgb2YgY29tcG9z aXRlIGJlY2F1c2UgYSBjb21wb3NpdGUgc29sdXRpb24gY2FuIGhlbHAgYnJpZGdlIGFjcm9zcyBh IHBhcmFtIGNoYW5nZSwgZm9yIGV4YW1wbGUgbWF5YmUgYnkgaW5jbHVkaW5nIG9uZSBzaWduYXR1 cmUgb24gZWFjaCBwYXJhbSBzZXQgdW50aWwgYWxsIGNsaWVudHMgYXJlIHVwZ3JhZGVkLiBJIHdp c2ggc3VjaCBhIG1lY2hhbmlzbSBoYWQgZXhpc3RlZCBzaW5jZSB0aGUgYmVnaW5uaW5nIG9mIFBL STsgaXQgd291bGQgaGF2ZSBoZWxwZWQgZm9yIGV4YW1wbGUgd2l0aCB0aGUgU0hBMSAtPiBTSEEy IG1pZ3JhdGlvbiBhcyB0aGVyZSBhcmUgKnN0aWxsKiBQS0kgZGVwbG95bWVudHMgd2l0aCBhIGhh bmRmdWwgb2YgY3JpdGljYWwgbGVnYWN5IGNsaWVudHMgdGhhdCBrZWVwIHRoZSBlbnRpcmUgZWNv c3lzdGVtIG9uIFNIQTEuIEluIGZhY3QsIEFGQUlLIE1pY3Jvc29mdCBjb2RlLXNpZ25pbmcgZGlk IGV4YWN0bHkgdGhhdCBieSBpbmNsdWRpbmcgYm90aCBTSEExIGFuZCBTSEEyIHNpZ25hdHVyZXMg b24gYmluYXJpZXMgYW5kIGxldHRpbmcgdGhlIHZlcmlmaWVyIHBpY2sgdGhlaXIgZmF2b3VyaXRl IGR1cmluZyB0aGUgdHJhbnNpdGlvbiBwZXJpb2QuIExldCdzIHN0YW5kYXJkaXplIHRoaXMgYmVm b3JlIHdlIGVuZCB1cCB3aXRoIGEgZG96ZW4gcHJvcHJpZXRhcnkgd2F5cyBvZiBqYW1taW5nIDIr IHNpZ25hdHVyZXMgb24gdGhpbmdzIQ0KDQotLS0NCk1pa2UgT3Vuc3dvcnRoIHwgT2ZmaWNlOiAr MSAoNjEzKSAyNzAtMjg3Mw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3Rl cGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiANClNlbnQ6IEphbnVhcnkg MTcsIDIwMjAgMjowNiBQTQ0KVG86IEpvaG4gR3JheSA8Sm9obi5HcmF5QGVudHJ1c3RkYXRhY2Fy ZC5jb20+OyBNYXJra3UtSnVoYW5pIE8uIFNhYXJpbmVuIDxtam9zQHBxc2hpZWxkLmNvbT47IElF VEYgU2VjRGlzcGF0Y2ggPHNlY2Rpc3BhdGNoQGlldGYub3JnPg0KQ2M6IERhbmllbCBWYW4gR2Vl c3QgPERhbmllbC5WYW5HZWVzdEBpc2FyYS5jb20+OyBNaWtlIE91bnN3b3J0aCA8TWlrZS5PdW5z d29ydGhAZW50cnVzdGRhdGFjYXJkLmNvbT4NClN1YmplY3Q6IFJlOiBbRVhURVJOQUxdUmU6IFtT ZWNkaXNwYXRjaF0gQ2FuIENvbXBvc2l0ZSBzaWdzIG1vdmUgYmFjayB0byBMQU1QUz8NCg0KDQpS ZXBseWluZyB0byBhIGZldyBtYWlscyBhdCBvbmNlLCBidXQgSVNUTSB0aGlzIGlzIHN0YXJ0aW5n IHRvIGdldCByZXBldGl0aXZlLg0KDQpPbiAxNy8wMS8yMDIwIDE4OjE1LCBKb2huIEdyYXkgd3Jv dGU6DQo+IEhpIFN0ZXBoZW4sDQo+IA0KPiBUaGUgcmVhc29uIHdoeSB3ZSBhcmUgcHV0dGluZyB0 b2dldGhlciB0aGlzIGNvbXBvc2l0ZSBzdGFuZGFyZCBpcyANCj4gYmVjYXVzZSB3ZSBiZWxpZXZl IHdlIGFyZSBpbiB0aGlzIHBvc2l0aW9uIHRvZGF5LiAgIElmIE5JU1QgIGRlY2lkZXMgDQo+IG5v IFJvdW5kIDMgaXMgbmVlZGVkLCB0aGVuIHdlIHdpbGwga25vdyB0aGUgUFEgd2lubmVycyBieSBK dW5lIG9mIA0KPiB0aGlzIHllYXIuICAgRXZlbiBpZiB0aGVyZSBpcyBhIFJvdW5kIDMsIGFuZCBu byBmaW5hbCBzZXQgb2YgUFEgDQo+IGFsZ29yaXRobXMgaXMgZGVjbGFyZWQgdW50aWwgMjAyMSBv ciAyMDIyLCB3ZSB3YW50IHRvIGhhdmUgYSBoeWJyaWQgDQo+IHN0YW5kYXJkIHJlYWR5IGZvciB1 cyB1c2UuICBXZSB3aWxsIG5lZWQgdG8gaW1wbGVtZW50LCB0ZXN0LCBhbmQgDQo+IGludGVyb3Ag YW5kIGFsbCB0aGVzZSB0aGluZ3MgdGFrZSB0aW1lIGFuZCBoYXZlIHRvIGJlIGRvbmUgYWZ0ZXIg dGhlcmUgDQo+IGlzIGEgc3RhbmRhcmQuICBJZiB3ZSB3YWl0IHRvbyBsb25nLCBpdCB3aWxsIGJl IGEgZnJlZSBmb3IgYWxsLg0KDQpSaWdodCBub3cgdGhlcmUgYXJlIHRvbyBtYW55IGFsZ29yaXRo bXMgdG8gYmVsaWV2ZSB0aGF0IHdlJ2QgaGF2ZSBvdGhlciB0aGFuIGEgZnJlZS1mb3ItYWxsIGFz IHRob3NlIHB1c2hpbmcgb25lIG9yIGFub3RoZXIgdHJ5IGdldCB0aGVpciB0aGluZyBhZG9wdGVk LiBJJ2QgYWxzbyBub3RlIHRoYXQgTklTVCBoYXMgYSBoaXN0b3J5IG9yIGRlZmluaW5nIG5ldyBw YXJhbWV0ZXJpc2F0aW9ucyBhZnRlciBhbGdvcml0aG0gc2VsZWN0aW9uLCBzbyB3b3VsZG4ndCBi ZSBzdXJwcmlzZWQgaWYgdGhhdCBoYXBwZW5lZCBoZXJlIHRvby4gSSdkIHByZWZlciB3ZSB3YWl0 IGFuZCBzZWUgd2hhdCByZXN1bHRzIGZyb20gdGhlIE5JU1QgdGhpbmcgcmF0aGVyIGFkb3B0IHdv cmsgbm93IGluIHRoZSBJRVRGLiBJZiBwZW9wbGUgd2FudCB0byBkbyB3b3JrIGFoZWFkIG9mIE5J U1QgdGhlbiB0aGF0J3Mgb2YgY291cnNlIGZpbmUsIGJ1dCBhZG9wdGluZyBzdWNoIHdvcmsgaW4g dGhlIElFVEYgaXMgYXNraW5nIHVzIGFsbCB0byBkbyB3b3JrIG9uIHRoaXMgbm93LCBhbmQgSSB0 aGluayB0aGF0J3MgYm90aCByaXNreSBhbmQgd2FzdGVmdWwuDQoNCj4gDQo+IFRoZXJlIGFyZSBh bHJlYWR5IGEgc21hbGwgaGFuZGZ1bCBvZiBzdGFibGUgUFEgYWxnb3JpdGhtcyBhdmFpbGFibGUg DQo+IHRvIHVzZSB0b2RheS4gICBTZWUgUkZDIDgzOTEgKFhNU1MpIGFuZCBSRkMgODU1NCAoTE1T KSwgc28gdXNpbmcgYSANCj4gaHlicmlkIFJTQSBvciBFQyB3aXRoIFhNU1Mgb3IgTE1TIGluIGEg Y29tcG9zaXRlIGZvcm0gaXMgYWxyZWFkeSANCj4gdmlhYmxlLiAgVGhlIGNob2ljZXMgYXJlIGRl ZmluaXRlbHkgZmV3IGF0IHRoaXMgbW9tZW50LCBidXQgdGhlcmUgYXJlIA0KPiB2aWFibGUgdXNl LWNhc2VzLg0KDQpTdGF0ZWZ1bCBzaWduYXR1cmUgc2NoZW1lcyBzdWNoIGFzIHRob3NlIGFyZSBu b3Qgc3VpdGVkIGZvciB1c2UgaW4gWC41MDkgSU1PLCBhcyB3YXMgYWxyZWFkeSByYWlzZWQgb24g dGhlIGxpc3QuDQooQW5kIHNvbWVvbmUgZWFybGllciBjbGFpbWVkIHRoZXkgd291bGRuJ3Qgd29y ayBmb3IgdGhlaXIgdXNlLWNhc2VzLCBzbyBJJ20gY29uZnVzZWQgYXMgdG8gd2hldGhlciB0aGUg cHJvcG9uZW50cyBoZXJlIGRvIG9yIGRvbid0IHdhbnQgdG8gaW5jbHVkZSBzdGF0ZWZ1bCBzaWdu YXR1cmUNCnNjaGVtZXMuKQ0KDQpPbiAxNy8wMS8yMDIwIDE3OjU0LCBNaWtlIE91bnN3b3J0aCB3 cm90ZToNCj4gQ29vbC4gSW4gdGhlIG1lYW50aW1lLCB3ZSBwbGFuIHRvIGtlZXAgd29ya2luZyBv biB0aGUgb3V0c3RhbmRpbmcgVE9ETyANCj4gZGVjaXNpb24gcG9pbnRzIGluIHRoZSBkcmFmdCBh cyBtb3JlIHZlbmRvcnMgYXBwcm9hY2ggdXMgZm9yIGludGVyb3AgDQo+IHRlc3RpbmcuIDotKQ0K DQpJJ3ZlIG5vIG9iamVjdGlvbiB0byBwZW9wbGUgd29ya2luZyBvbiBzdHVmZi4gSSBhbSBvcHBv c2VkIHRvIHRoZSBJRVRGIHByZW1hdHVyZWx5IGFkb3B0aW5nIHdvcmsgaW4gdGhpcyBzcGFjZSB0 aG91Z2guDQoNCk9uIDE3LzAxLzIwMjAgMTg6MDgsIENhcnJpY2sgQmFydGxlIHdyb3RlOg0KPiBG cm9tIHdoYXQgSSd2ZSBnYXRoZXJlZCBmcm9tIHRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiBv biB0aGlzIHRvcGljIA0KPiAoaW4gcGFydGljdWxhciwgdGhlIGxlYWQgdGltZSBuZWNlc3Nhcnkg Zm9yIGhhcmR3YXJlKSwgaXQgc3RyaWtlcyBtZSANCj4gdGhhdCB0aGVyZSBpcyBzdWZmaWNpZW50 IHJlYXNvbiBmb3IgdGhpcyB3b3JrIHRvIGFkdmFuY2UuDQoNCk15IGV4cGVyaWVuY2UgaW4gdGhl IElFVEYgaXMgdGhhdCBpbGwtZGVmaW5lZCBhbmQgbGVzcyB3ZWxsIHVuZGVyc3Rvb2Qgd29yayB0 YWtlcyBsb25nZXN0LiBJIHRoaW5rIHRoaXMgbWF0Y2hlcyB0aGF0IGF0IHRoZSBtb21lbnQuIEkn ZCBzdWdnZXN0IHRoZSBwcm9wb25lbnRzIG1pZ2h0IGJlIGJldHRlciBzcGVuZGluZyB0aW1lIG9u IGRldmVsb3BpbmcgdGhlaXIgd29yayBieSBpbXBsZW1lbnRpbmcgaXQgaW4gb3Blbi1zb3VyY2Ug Z2VuZXJpYyBQS0kgbGlicmFyaWVzIGFuZCBhcHBsaWNhdGlvbnMgc28gdGhhdCB0aGV5IGNhbiBw cm9kdWNlIHNvbWUgbm9uIGFybS13YXZpbmcgZXZpZGVuY2UgYXMgdG8gd2hhdCB0aGlzIGRvZXMg b3IgZG9lc24ndCBicmVhay4gKElNTywgaXQnbGwgdHVybiBvdXQgdG8gYnJlYWsgYSBsb3QgYW5k IGNoYW5nZSBtYW55IGxpbmVzIG9mIGNvZGUsIGJ1dCB3aG8ga25vd3MsIEkgbWF5IGJlIHdyb25n LikNCg0KT24gMTcvMDEvMjAyMCAxODozMiwgVmFsZXJ5IFNteXNsb3Ygd3JvdGU6DQo+IEdpdmVu IHRoZSB1c3VhbCBJRVRGIHBlcmZvcm1hbmNlLCBhIHllYXIgaXMgYSB0ZXJtIGp1c3QgdG8gbGF1 bmNoIGEgDQo+IHJlYWwgd29yayBhbmQgcmVhbGl6ZSB3aGVyZSB0byBnby4gU28sIEkgdGhpbmsg d2Ugc2hvdWxkIHN0YXJ0IGRvaW5nIA0KPiBpdCBub3cgdG8gaGF2ZSBwbGVudHkgb2YgdGltZSBh bmQgbm90IHRvIGJlIGluIGEgaHVycnkgbGF0ZXIuDQoNClNlZSBhYm92ZSBhcyB0byBob3cgdG8g c3BlZWQgdGhpbmdzIHVwIG1vcmUgZWZmZWN0aXZlbHkuDQpBZGRpdGlvbmFsbHksIHRoZSBpZGVh IHRoYXQgd2FpdGluZyBhIHllYXIgb3Igc28gbWVhbnMgc29tZW9uZSB3b3VsZCBoYXZlIHRvICJi ZSBpbiBhIGh1cnJ5IiBzZWVtcyBxdWVzdGlvbmFibGUgdG8gbWUuDQoNCkNoZWVycywNClMuDQoN Cg0K From nobody Fri Jan 17 14:21:48 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B857E12008D for ; Fri, 17 Jan 2020 14:21:46 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 YxyVfzkRf_bD for ; Fri, 17 Jan 2020 14:21:45 -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 B5104120026 for ; Fri, 17 Jan 2020 14:21:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C70FCBE20; Fri, 17 Jan 2020 22:21:42 +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 jC7sPbYCcXUM; Fri, 17 Jan 2020 22:21:41 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2CB02BDCF; Fri, 17 Jan 2020 22:21:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579299701; bh=hxo4vLTTe2TFD3PDG1PjUisboXgYKSGMRjcCPid/VZc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=1APWuAWWO66XjDzlS0L/TvbBnsPbusCp3uHpb7svamGPVANUhDwJvv/RW3qj/hTPr ZP9xW+rPdN4IBP7IJWUZYw+v3b0YOVXI1niBrOgT7k1ujGAB62SjBs1rFGDERaK8MM puCe5anASX0r0MmZsVwBYaJCq7azhG99gtYSwEPM= To: Mike Ounsworth , John Gray , "Markku-Juhani O. Saarinen" , IETF SecDispatch Cc: Daniel Van Geest References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> From: Stephen Farrell 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: <58549908-d472-20f7-6026-52adb088a62d@cs.tcd.ie> Date: Fri, 17 Jan 2020 22:21:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9HRh2VbsXYfZb5l1yFbPvd3p62FhLWimW" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:21:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9HRh2VbsXYfZb5l1yFbPvd3p62FhLWimW Content-Type: multipart/mixed; boundary="pN3ub1wnxhzU2SjTbhob28cxIeS5IbdPC"; protected-headers="v1" From: Stephen Farrell To: Mike Ounsworth , John Gray , "Markku-Juhani O. Saarinen" , IETF SecDispatch Cc: Daniel Van Geest Message-ID: <58549908-d472-20f7-6026-52adb088a62d@cs.tcd.ie> Subject: Re: [EXTERNAL]Re: [Secdispatch] Can Composite sigs move back to LAMPS? References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> In-Reply-To: --pN3ub1wnxhzU2SjTbhob28cxIeS5IbdPC Content-Type: multipart/mixed; boundary="------------D457F284AB359D4321E4D2F8" Content-Language: en-US This is a multi-part message in MIME format. --------------D457F284AB359D4321E4D2F8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/01/2020 22:17, Mike Ounsworth wrote: > You keep mentioning parameter sets and "what if they change?". I > really don't see why that's relevant. Running code. Introduction of new failure modes in already- notoriously brittle code. It may be easy to write the ASN.1 module, but that's only a tiny bit of the work and (from experience) easy to get wrong in the absence of real code. S. --------------D457F284AB359D4321E4D2F8 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------D457F284AB359D4321E4D2F8-- --pN3ub1wnxhzU2SjTbhob28cxIeS5IbdPC-- --9HRh2VbsXYfZb5l1yFbPvd3p62FhLWimW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4iM3MACgkQWrL68XsX K+qZExAAv2EjUGBrJxxqr1qMATOHq7FSL57F9dXVDILEEtjmZ8WWM1Sbvr4wKRGL J59QEekhnemQxCK8JMTizFhOsb3qdjYQWTBbeSpAghnH+bcImVtjxKJYAxmcmYs2 AHdBoPeH6JFK1r0Rl/LyrfKUWZ9cE5SGZyccfE8f/3GusHjqROyR2r6N8TB55EzX StihyD/F5aw2IuzjmnEQ1F3fcKlhAav1IqMZf2CkFSV/50mcuBT5jUiSTb30b8ZC hQyaP/vTDYpxsYdN0hOT7FsCr/MvCTtiNJi6wFAc+Rbaicx7vp9rawcdoCNwe6JP V810eGakKc9IBexHsmgWX1hPtpdgfVo8vCrPetCmIsAyHLzmm9iWmr0i4DbWi8ag 9ZJ5SMTiDCegRy5yxt7E8oakfW0QCOFXS1pSTXfuYqbnKzHxSxDynf8DRMh3AWL+ qvKza7AQJ9RDHfZ4B46bWRXbycvVR52i6Bbb+ZgcRskZ/fqtvugiIscBjoq6pekq 2IeGdzgxVEfVJoAvj7YOj28hgKTVS4EJzjZ25Sco2f9hB5zNE6gjVZfCgFoHGpvA YdUyNR4YHLAmzN8hMcfss/wX+09cIYgfzCM5yJyS3vp+F3dCXqo2JjOGLdNu65lD BLwFueJ3djl2xTc33l2ELVu1ywIKK+7MjozzOeck6JT5LSAo84g= =4Niu -----END PGP SIGNATURE----- --9HRh2VbsXYfZb5l1yFbPvd3p62FhLWimW-- From nobody Fri Jan 17 15:05:07 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C3212008A for ; Fri, 17 Jan 2020 15:05:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pqshield-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zCWKrChr3T1 for ; Fri, 17 Jan 2020 15:05:05 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 1CD82120086 for ; Fri, 17 Jan 2020 15:05:05 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id d71so24421726qkc.0 for ; Fri, 17 Jan 2020 15:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Mdf3VKOKJNm/qDfbbvOTU8Y0pwhp0Zc19Vj8g4Esek=; b=kbbRhk5GRmrRnxOL7+GoYGDBenmNaLOixgOF2mlXSVIY4dkE05gT9u4cgSKEnGZsyG uCDiVV7Fok88dK9tuFXBCgOXquudH1+G0yMj1M5uOVFFrqfUs8XF7d4RimK0FLosaneu YU9l8tbCpACvn/8b46kBG9+IQmGKvylfW4O16/XnY+r8pkdBRu4PQgOW31BU97QFOgUp SaEovZVpEb/NK0WiXdgYiwJ1EAPJOuNeW/74a/k3RtGP38H0904sLQ9AjptnJOGqqFzp XPTbvADNmxNocCfs6mgsXonIxli/1bbNPxlUAenUrw//uS+bj7XJeJiEYCTTQB6WJlYP KvDA== 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=8Mdf3VKOKJNm/qDfbbvOTU8Y0pwhp0Zc19Vj8g4Esek=; b=hFPSTKBbDggg/mMJM8HRxIkNehhxSCP/5fzyUWskaGEl+zgjnbYOO3OwFPD7GKK61j b6AYXsA9P3CLVAXlSLpaSFkU+MV7EwvHrlaWJ7gnkX07Yu8Cek2viMs/Co0Z6XIORaJD fz2xJgH3R1nHk8ySSdvbp4Ixe7mW272UAD0yfBIUMXy8yVsWscL9+2p2C+Eq65HlBSCg obWF2sRTmdBtn5IKVL1N5nc834Nnpb716xk8WKeZEL2FrcA464Mdu1d8rPFl3NweIlWC ZusldrD7Mmg6EmBGtyO5ON3TyFM7yHvxh9AkjQ1kPTpXiunHDawP16J3n9nAI4/QyXJj 7ayQ== X-Gm-Message-State: APjAAAVGcvycGjktxModXDs4gjKdHtFfBYk8OJGiMMi7sx9XZ45VL7oZ 1022mgL77ugJkxg6JxxbOgJalpOHKyHlIBBYotexPA== X-Google-Smtp-Source: APXvYqxR4bay+qWfGnxjkWvAuLEm0vuVdk3R9Lg8u+urTaCd4p0owZqkEORgRReXO3iHoRWtqyGQT/Q0mehVXSljCP4= X-Received: by 2002:a37:f514:: with SMTP id l20mr39564152qkk.421.1579302304218; Fri, 17 Jan 2020 15:05:04 -0800 (PST) MIME-Version: 1.0 References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <58549908-d472-20f7-6026-52adb088a62d@cs.tcd.ie> In-Reply-To: <58549908-d472-20f7-6026-52adb088a62d@cs.tcd.ie> From: "Markku-Juhani O. Saarinen" Date: Fri, 17 Jan 2020 23:04:53 +0000 Message-ID: To: Stephen Farrell Cc: Mike Ounsworth , John Gray , IETF SecDispatch , Daniel Van Geest Content-Type: multipart/alternative; boundary="000000000000d615d8059c5df880" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 23:05:07 -0000 --000000000000d615d8059c5df880 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 10:21 PM Stephen Farrell wrote: > > > On 17/01/2020 22:17, Mike Ounsworth wrote: > > You keep mentioning parameter sets and "what if they change?". I > > really don't see why that's relevant. > > Running code. Introduction of new failure modes in already- > notoriously brittle code. It may be easy to write the ASN.1 > module, but that's only a tiny bit of the work and (from > experience) easy to get wrong in the absence of real code. Most people here know that we've had running code for "hybrid/composite certificates" for years, e.g. an open one via OQS ( you go and play with those certs at https://github.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_1_1-stable ) and a proprietary ones via Isara and DigiCert. The problem is not that there is no running code, the problem is that there is too much running code and it does not talk to each other due to lack of IETF-supported standardization. Anyway, as Mike noted, we'll just do the spec, interop with industry partners and go from there. Cheers, - markku Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. --000000000000d615d8059c5df880 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 10:21 PM Stephen = Farrell <stephen.farrell@cs= .tcd.ie> wrote:


On 17/01/2020 22:17, Mike Ounsworth wrote:
> You keep mentioning parameter sets and "what if they change?"= ;. I
> really don't see why that's relevant.
=C2= =A0
Running code. Introduction of new failure modes in already-
notoriously brittle code. It may be easy to write the ASN.1
module, but that's only a tiny bit of the work and (from
experience) easy to get wrong in the absence of real code.

Most people here know=C2=A0that we've had running code = for "hybrid/composite certificates" for years, e.g. an open one v= ia OQS ( you go and play with those certs at=C2=A0https://githu= b.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_1_1-stable=C2=A0) an= d a proprietary ones via Isara and DigiCert.=C2=A0

The problem is not that there is no running code, the problem is that ther= e is too much running code and it does not talk to each other due to lack o= f IETF-supported standardization.

Anyway, as Mike = noted, we'll just do the spec, interop with industry partners and go fr= om there.=C2=A0

Cheers,
- markku=C2=A0

Dr. Markku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK.<= /div>
--000000000000d615d8059c5df880-- From nobody Sat Jan 18 08:24:39 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0213120077 for ; Sat, 18 Jan 2020 08:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PzMxT-mAKee for ; Sat, 18 Jan 2020 08:24:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08B312002F for ; Sat, 18 Jan 2020 08:24:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 363BC3897A for ; Sat, 18 Jan 2020 11:24:05 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 54764C4C for ; Sat, 18 Jan 2020 11:24:34 -0500 (EST) From: Michael Richardson To: IETF SecDispatch In-Reply-To: References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 16:24:38 -0000 --=-=-= Content-Type: text/plain Mike Ounsworth wrote: > Draft-ounsworth-pq-composite-sigs defines ASN.1 structures for carrying > multiple SubjectPublicKeyInfo, AlgorithmIdentifier, and BIT STRING > (signature values), in a way that will be drop-in for PKIX-like > protocols. > You keep mentioning parameter sets and "what if they change?". I really > don't see why that's relevant. Draft-ounsworth-pq-composite-sigs is > algorithm-agnostic; orthogonal to the choice of algorithms by NIST or > their encodings. In particular, it seems to me that we could add these multiple entries to certificates, using dummy algorithms, and test them in the field against existing browsers, web servers, IDS, firewalls, etc. We know that this system has to work with systems that don't understand it yet. I don't know if LAMPS is the right group though. It feels like it needs a new WG. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4jMUIACgkQgItw+93Q 3WV/tAgAqRY6aNWp27Ac+VTYCT2PLGRYtWPCUKIUMCGfWtFL721ko9qDkh4OB5oL Gkh1X3/M+VhZkQFScQVjJgigXyCzqgDbpw4J8Gl4+Np/WekFxSuvPR9kD8xWIk1+ GxooqG2rqHnw8hYLYc9hz8Hc1n3iB2EMaFjHHTytbGJcV2RrTC7g5eVqrFERLk3D 3BXF04XVqquKY87Qqe04K7z6Ylo1hedXOIhQTCqiiWgdS9rjfly4gjJJNK7+iR3D 7AeyxJfki1WWXUBpFgDswZoVHYMlOOdSuyhThdxft2VE9MHmDy+E18vvmTROPybc bD7ezExwsPkP2/psmXyufHtAj7qfIQ== =TGo2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jan 18 11:59:23 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E072120043 for ; Sat, 18 Jan 2020 11:59:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BdOaPUzPyiv for ; Sat, 18 Jan 2020 11:59:18 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 681FB120019 for ; Sat, 18 Jan 2020 11:59:18 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id r14so20945555lfm.5 for ; Sat, 18 Jan 2020 11:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xj+ffqUWHkivQ0VdyUusKowdMOiiyBRmtJXiMO4+MWI=; b=ZBQFV2beuU5o0Eo3TVKDRjYMB6bTJiMnZL6A9EBJuN6DS+TjEnbM4qjeFPM7mB0t6s D9XbWc8Y+bc3QM7DVSljAMEsCMFlnPU5oZvtMMzyueksFtRN+PGaq3e4qzNjF9F4y0wv b7TVjjhOJZCFQTfj0yMGFeX/y5gAy/tSfXBmE6b1Ijz9SkuJkMnROk+AIunv0jusrvWv OrnKVev+v6Bj1VAzzreYXQxeQrpr1yqp/8bPbcWQq078UVwoX2nAYchocEEsQtsuloD5 Lbk4IvuH3JfHtjV/KZAfdtPEKj0JsEB74dkXARpHdsD51JoL2Pht4ieaIQXOXGiaZlKa LYlQ== 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=xj+ffqUWHkivQ0VdyUusKowdMOiiyBRmtJXiMO4+MWI=; b=h6ijp7bCuX1Iaxl1iZeRoXKmMMPhjaJdHqk7PNAbRLkNlQmV/5oOcmB3NaovrSVTzS B+BSdszBeRB0PC9xRe+H2wUkZ5PhFzrFqnjWyRSWTuBsRrODq/2JMGSHPxBjTNbpjBgD eMyvdhG3Rrgbu4VjTcyHQTVX+PElW68Nn8kMpSy11Ijnt9qyQK21yIzHzcrRQwcBGS+n VYuAodi8aUaOFC3arZzmzbLnp/ivtAPTbkrHaowpyUCtjzjgw6odP5DCF+BIvf9f+xRt DyyXDAvcc571Cq0ljxCT2kqTwqbjdr4aksOxfkMA2FK4ZARVz5eJD5xKfvhKo6fxWCW/ mJzw== X-Gm-Message-State: APjAAAVujFcybQQxIdYy272v7yKrFqZQ+1s8VFnhwwxVICSiw2ItjQo9 eZ+8ANV0as2X79uVwUfgPypV/eLR9IEmoyUAvwK8Ww== X-Google-Smtp-Source: APXvYqy+iExOa377zJCx9VTz8OSzJ9+grZsLIJYqlQx/sNKgW57B6pRqYWF6E15EDKItaX5V29KlYscmZzsbatqMVIw= X-Received: by 2002:a05:6512:284:: with SMTP id j4mr8789950lfp.109.1579377556478; Sat, 18 Jan 2020 11:59:16 -0800 (PST) MIME-Version: 1.0 References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <3140.1579364674@localhost> In-Reply-To: <3140.1579364674@localhost> From: Eric Rescorla Date: Sat, 18 Jan 2020 11:58:39 -0800 Message-ID: To: Michael Richardson Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000003872a5059c6f7e6a" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 19:59:21 -0000 --0000000000003872a5059c6f7e6a Content-Type: text/plain; charset="UTF-8" On Sat, Jan 18, 2020 at 8:24 AM Michael Richardson wrote: > > Mike Ounsworth wrote: > > Draft-ounsworth-pq-composite-sigs defines ASN.1 structures for > carrying > > multiple SubjectPublicKeyInfo, AlgorithmIdentifier, and BIT STRING > > (signature values), in a way that will be drop-in for PKIX-like > > protocols. > > > You keep mentioning parameter sets and "what if they change?". I > really > > don't see why that's relevant. Draft-ounsworth-pq-composite-sigs is > > algorithm-agnostic; orthogonal to the choice of algorithms by NIST or > > their encodings. > > In particular, it seems to me that we could add these multiple entries to > certificates, using dummy algorithms, and test them in the field against > existing browsers, web servers, IDS, firewalls, etc. > It's not quite clear to me how this would work. As I understand it, this involves replacing the existing public keys and signatures, in which case they won't be acceptable to any Web browser (and you in fact won't be able to get BR-compliant certs).... -Ekr > We know that this system has to work with systems that don't understand it > yet. > > I don't know if LAMPS is the right group though. > It feels like it needs a new WG. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000003872a5059c6f7e6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 18, 2020 at 8:24 AM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com> wrote:
=C2=A0 =C2=A0 > Draft-ounsworth-pq-composite-sigs defines ASN.1 structur= es for carrying
=C2=A0 =C2=A0 > multiple SubjectPublicKeyInfo, AlgorithmIdentifier, and = BIT STRING
=C2=A0 =C2=A0 > (signature values), in a way that will be drop-in for PK= IX-like
=C2=A0 =C2=A0 > protocols.

=C2=A0 =C2=A0 > You keep mentioning parameter sets and "what if the= y change?". I really
=C2=A0 =C2=A0 > don't see why that's relevant. Draft-ounsworth-p= q-composite-sigs is
=C2=A0 =C2=A0 > algorithm-agnostic; orthogonal to the choice of algorith= ms by NIST or
=C2=A0 =C2=A0 > their encodings.

In particular, it seems to me that we could add these multiple entries to certificates, using dummy algorithms, and test them in the field against existing browsers, web servers, IDS, firewalls, etc.
<= br>
It's not quite clear to me how this would work. As I unde= rstand it, this involves replacing the existing public keys and signatures,= in which case they won't be acceptable to any Web browser (and you in = fact won't be able to get BR-compliant certs)....

-Ekr


We know that this system has to work with systems that don't understand= it
yet.

I don't know if LAMPS is the right group though.
It feels like it needs a new WG.

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



_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000003872a5059c6f7e6a-- From nobody Sat Jan 18 13:13:55 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FD1120019 for ; Sat, 18 Jan 2020 13:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 914Nrp2LCkus for ; Sat, 18 Jan 2020 13:13:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F18412008B for ; Sat, 18 Jan 2020 13:13:51 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 784443897A; Sat, 18 Jan 2020 16:13:21 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AFBB9825; Sat, 18 Jan 2020 16:13:50 -0500 (EST) From: Michael Richardson To: Eric Rescorla cc: IETF SecDispatch In-Reply-To: References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <3140.1579364674@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 21:13:54 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: mcr> In particular, it seems to me that we could add these multiple mcr> entries to mcr> certificates, using dummy algorithms, and test them in the field mcr> against mcr> existing browsers, web servers, IDS, firewalls, etc. > It's not quite clear to me how this would work. As I understand it, > this involves replacing the existing public keys and signatures, in > which case they won't be acceptable to any Web browser (and you in > fact won't be able to get BR-compliant certs).... No, it involves two sets of signatures. The traditional set and the new, yet-to-be-precisely-defined set. It could be that CAFORUM rules would presently prevent these certificates From=20going into production, and during an experiment, that would be okay,= I think. The reason to start this work now is to wring out the obsticales such as BR/CABFORUM rules that would prevent/slow-down adoption. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4jdQ4ACgkQgItw+93Q 3WVshQf+KAU/67fzgxqBul1cWjdsIeLbfH5ne2SY0+NA3GvxItOw7tYVq698HGpM IYQJF/V88cRpHfw0IkcCQ0cmMfiW8MNTRX3sQSi+reOgYmQrbe86B5sfyKRs1UUk x5RKtA92P2dcij8c+FeAcLTTg+i+ClDVTzLnL0eaURj1QIoktIBvFl+J29AeVQCH BVFOLzOsQljfzTNXJ0+XZIV0vrcOvqfFgIIpPmFZopi/HRegWdP/YTZmDZGZqNJw D1Fh2No0Ove7jclSqSWkFSOThn+8OQPH6hSUQMO1qdOUDExtItnibqeaVUU6v8M4 b1zMy7CDWpEMCEFy72iNAyHdu52lyw== =2Yz+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jan 18 13:32:05 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADE2120074 for ; Sat, 18 Jan 2020 13:32:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRlCewY-pw1r for ; Sat, 18 Jan 2020 13:32:01 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F23120019 for ; Sat, 18 Jan 2020 13:32:01 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id h23so30036548ljc.8 for ; Sat, 18 Jan 2020 13:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HMlFgVhBC5iVBRQlT8fuEYwHwdcxtUcmBZ46k8ZpzVc=; b=E+S/eU76KMlYcgbcMq2N+TYOqw8JuCGAZDO7yHEAosfULMvdWopuQEeSGZ33PnX+B1 0u7vM8ypAvaJKLeekNl/f6neeWjTnjMQ8EVYTk9MC6Xrw9sWwuZOIFVGYrRHKYNHziR7 C3gqP5D7isg8DSKNBvJ5OcdQHkMpvcsPupW+bhw8f708rPMSnDNw/Wb9kNu+aggos2Kj R46uPOUQpHXtRNOZCdxE/gw8dj97b9Vrv5hpo+ChJ7AcjKUD+niB5RsN6+NfkOCBrIQa HNM2RZPAH5cuwEzhjhUF6HfF9j+mM1qPzmd/wvODK9H/QVYkxVCDvjA9RKBNxBmVeUHB KOOg== 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=HMlFgVhBC5iVBRQlT8fuEYwHwdcxtUcmBZ46k8ZpzVc=; b=Nie8dHqU1sX7VCzu4gHRsJrw2sOyaujfEv5z5ByJ9ZNJFS9RIXmgZyL0E60qCZXPUD v4y0Dxx9bZxVAHcHB2B48nMfdoQufPVF0BG3djelmEsuCq5RRuT1ahIMkFRItTf9squS I/T6UZqM+b5LO2QwW5T2xhF0EyxOInNJTtr8RVHwpJX/2HsSJE3ehO8mpj+QH1jvWI9V HmUwqNQ92qgewhRxBdehlFnhfnuUP4y8acs8fYlq7+aWKOljnHxYQr6+Yno1gxeepVfn k3J+qlGB1VhlH+f4nCk+6OkBVrHHueNWERyldow7ttDjWFQkI4cPP7USm09N4dNAk5aM 98KQ== X-Gm-Message-State: APjAAAXnZ5svc4XHqPpmg64LiW5dNuWPoieSgMu+fGP0/EcZ1J7tyqDU +gFDyDIPWzUy3k/SzvfWuE+ev7AFByJz1rtEgd5e+g== X-Google-Smtp-Source: APXvYqyECaS9UjHfQhgfNf7dkaipgUWJc+Q1dgA3y6cyq44cWoJ1R7uCOQD9Wibq/ZBpFVAJqZU0h599B1ZPS3Lp3S0= X-Received: by 2002:a2e:b0e3:: with SMTP id h3mr9151646ljl.56.1579383118998; Sat, 18 Jan 2020 13:31:58 -0800 (PST) MIME-Version: 1.0 References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <3140.1579364674@localhost> <15967.1579382030@localhost> In-Reply-To: <15967.1579382030@localhost> From: Eric Rescorla Date: Sat, 18 Jan 2020 13:31:22 -0800 Message-ID: To: Michael Richardson Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000c5c100059c70c90e" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 21:32:04 -0000 --000000000000c5c100059c70c90e Content-Type: text/plain; charset="UTF-8" On Sat, Jan 18, 2020 at 1:13 PM Michael Richardson wrote: > > Eric Rescorla wrote: > mcr> In particular, it seems to me that we could add these multiple > mcr> entries to > mcr> certificates, using dummy algorithms, and test them in the field > mcr> against > mcr> existing browsers, web servers, IDS, firewalls, etc. > > > It's not quite clear to me how this would work. As I understand it, > > this involves replacing the existing public keys and signatures, in > > which case they won't be acceptable to any Web browser (and you in > > fact won't be able to get BR-compliant certs).... > > No, it involves two sets of signatures. > The traditional set and the new, yet-to-be-precisely-defined set. > Yes, but I had understood these tbe encoded on the wire as if they were a new signature algorithm, with the result that such a certificate would not be verifiable by an existing client. Perhaps we should resolve this question first. -Ekr > It could be that CAFORUM rules would presently prevent these certificates > From going into production, and during an experiment, that would be okay, I > think. > > The reason to start this work now is to wring out the obsticales such as > BR/CABFORUM rules that would prevent/slow-down adoption. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --000000000000c5c100059c70c90e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 18, 2020 at 1:13 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 mcr> In particular, it seems to me that we could add these= multiple
=C2=A0 =C2=A0 mcr> entries to
=C2=A0 =C2=A0 mcr> certificates, using dummy algorithms, and test them i= n the field
=C2=A0 =C2=A0 mcr> against
=C2=A0 =C2=A0 mcr> existing browsers, web servers, IDS, firewalls, etc.<= br>
=C2=A0 =C2=A0 > It's not quite clear to me how this would work. As I= understand it,
=C2=A0 =C2=A0 > this involves replacing the existing public keys and sig= natures, in
=C2=A0 =C2=A0 > which case they won't be acceptable to any Web brows= er (and you in
=C2=A0 =C2=A0 > fact won't be able to get BR-compliant certs)....
No, it involves two sets of signatures.
The traditional set and the new, yet-to-be-precisely-defined set.

Yes, but I had understood these tbe encoded on t= he wire as if they were a new signature algorithm, with the result that suc= h a certificate would not be verifiable by an existing client.

Perhaps we should resolve this question first.
=
-Ekr



=C2=A0
It could be that CAFORUM rules would presently prevent these certificates >From going into production, and during an experiment, that would be okay, I=
think.

The reason to start this work now is to wring out the obsticales such as BR/CABFORUM rules that would prevent/slow-down adoption.

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



--000000000000c5c100059c70c90e-- From nobody Sun Jan 19 08:52:20 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1985912003F for ; Sun, 19 Jan 2020 08:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zte7D8gxDwTO for ; Sun, 19 Jan 2020 08:52:17 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F102E12002E for ; Sun, 19 Jan 2020 08:52:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 889853897A; Sun, 19 Jan 2020 11:51:45 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7391FC9B; Sun, 19 Jan 2020 11:52:15 -0500 (EST) From: Michael Richardson To: Brian Campbell cc: "secdispatch\@ietf.org" In-Reply-To: References: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] [saag] SECDISPATCH WG Summary from IETF 106 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 16:52:19 -0000 <#secure method=pgpmime mode=sign> Brian Campbell wrote: > Apologies folks, I'm responsible for the rushed and awkward > presentation about reverse proxies and TLS client certificates at the > very end of the SECDISPATCH session in Singapore, which is mentioned > below with "no draft yet--> needs draft". It took me a little while to > get through the work but I'm happy to share that there is now an > actual draft available. Here it is in the fancy new HTML format: > https://www.ietf.org/id/draft-bdc-something-something-certificate-01.html > as Thanks for this document. I think it is useful and important work. {"something-something" sounds like something that Winnie the Pooh would ask to eat for lunch} draft-ietf-anima-bootstraping-keyinfra (aka BRSKI) makes use of TLS Client Certificates in the Registrar. I have a document on operational considerations for Registrars, draft-richardson-anima-registrar-considerations and I've added your document as reference. In section 1, you may wish to reference: https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface although I can't find a section in https://www.python.org/dev/peps/pep-3333/ that describes the Client Certificate variable. I use "SSL_CLIENT_CERT" and more recently, "rack.peer_cert" in my code. ** I would like to have access to the entire client certificate *chain* ** Not just the End-Entity certificate. If any internal trust anchors were used to validate the chain, I also would prefer to receive them as well. Finally, I need to be able to configure the reverse proxy to do the TLS operation on the assumption that the certificate validates, even if the reverse proxy does not know how to validate the certificate chain itself. I need, therefore, to know if the certificate chain was validated, or not. You write: Forward proxies and other intermediaries MUST NOT add the Client-Cert header to requests. but, the reverse proxy can not control what is sent to it, and you shouldn't try to write normative language there. You already handle this: 2) Any occurrence of the Client-Cert header in the original incoming request MUST be removed or overwritten before forwarding the request. and leave it like that, maybe emphasis this. Maybe reverse proxies SHOULD reject requests that have a Client-Cert header in them, period? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sun Jan 19 08:59:24 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642A412001A for ; Sun, 19 Jan 2020 08:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fF2966vHDuO for ; Sun, 19 Jan 2020 08:59:20 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42BDD120013 for ; Sun, 19 Jan 2020 08:59:19 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 004BF3897A; Sun, 19 Jan 2020 11:58:48 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E3771C9B; Sun, 19 Jan 2020 11:59:18 -0500 (EST) From: Michael Richardson To: Eric Rescorla cc: IETF SecDispatch In-Reply-To: References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <3140.1579364674@localhost> <15967.1579382030@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 16:59:23 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: mcr> In particular, it seems to me that we could add these multiple mcr> entries to certificates, using dummy algorithms, and test them in mcr> the field against mcr> existing browsers, web servers, IDS, firewalls, etc. >> It's not quite clear to me how this would work. As I understand it, >> this involves replacing the existing public keys and signatures, in >> which case they won't be acceptable to any Web browser (and you in >> fact won't be able to get BR-compliant certs).... mcr> No, it involves two sets of signatures. mcr> The traditional set and the new, yet-to-be-precisely-defined set. > Yes, but I had understood these tbe encoded on the wire as if they > were a new signature algorithm, with the result that such a > certificate would not be verifiable by an existing client. > Perhaps we should resolve this question first. I believe that one proposal was to define a new signature type: RSA -> F { RSA, PQ } ECDSA -> G { ECDSA, PQ } and then, as you say, that would not interoperate at all. But, I think that another proposal is to introduce the additional signatures and related book-keeping as extensions, without disrupting the current signature mechanisms. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4kiuYACgkQgItw+93Q 3WWglggAsGwUNd4kiFUYQtt1YWuctDYB+AWfvZtcdCxWAcZTuEyytuV+ZV+vRCA6 X87rXNK6CYrD/PoZgeiHiyTxhJJ59CeOV/ocDyk56rqlLkNgrJv0OtMKasMHDExc h1PrbOGU2O1XtXwfjbnhuA9s9k7NIelU8i1dBIdrCEiFIog71fzBhbWAU6uLffJf CzXzAW0rVIweX97grDjuAN47YzVvj3Hy6AsOg+Pm7/nSoPT/5dEAomPdh96XBLQK 3ZcYSk9CbBPKza76sm+jW4ByzSM6upaREJRUQHekX9MCkL3C5EuNjN4qmZLfVouF 1FsILIlcGGPg0Qr32CllDgjZgefc0w== =qBzn -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 19 11:22:46 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D6D12001E for ; Sun, 19 Jan 2020 11:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pqshield-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttLfPN0EWK1D for ; Sun, 19 Jan 2020 11:22:41 -0800 (PST) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 A0A46120018 for ; Sun, 19 Jan 2020 11:22:41 -0800 (PST) Received: by mail-qt1-x841.google.com with SMTP id k40so26034968qtk.8 for ; Sun, 19 Jan 2020 11:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0SM6X5+f16bGr2g9WPuZfYZ4qiB7pRQbwyry+Bvm8GI=; b=m40Z5dc+Z8eKib6btTR5aopG3GxtX9X3xE1BTVLRlcU8MPCcYv/ylSUrEa01OoNzw9 c2ruSx638eTmG1Yt+DL73OxTQ+mUCUZ4tJy+dtRa46395oIwN72MWeO/wWqg3BSJQrED 3IvpNc4OXX+72ph/N/2VZYl6TTJvKBnIW8QDR8EaKcDxh3gyXp8k9lbNQHJHDFfwjR7P dwMCGPIU1+fKV/sU4nNaCWLiDO1rlN16q3BTOl7GoZyfU9lSRsnzf/QlnKybsDVhoxua JOLFDwGPBWfCYvZ3MHrMI/KJBvdQGL87BB6zMKqS9Kk3c9APLnUpZmkUgfwawewXvSZb ic8A== 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=0SM6X5+f16bGr2g9WPuZfYZ4qiB7pRQbwyry+Bvm8GI=; b=t3svZHfDNICUD3+pO/1dhjfIwkHdyBS3IxNopEdTOpnRCTIdxzi3/yFg8Ci0gb/1Ek DPtQXJtcnB9j9XgaHybC3ZJ1UaPJi/7m6KVEwupjZJ3gah1N5GrX5wwOxm7fsQ7oFy0V diXfsYzy15FbmML8F95s3poZJuhOGmsWyCtjfacIf25onmk4veaN3X+Rz4RrrP9xpZVn 1UlxOtgK5mxhgLO7CzzAMu7HP8fDKfQqZcqwRn9Cfg4kOLhEEVihyksNcBCLuLVSKlUk CA+8ED8Atn5vUd8kLPPDSjmCRGBwfPeYVDKRNCI69kbveWGRE5elpfCf3LpNSYLHwKkA GxfQ== X-Gm-Message-State: APjAAAWYdj40P76nsItoEbPR39HwSeXgLYv9PEd+UcOswSj0R7GwZbXM fb3ku3gQp10eWbD6o0RpQ+tMxYXKuf95BuNq41ymCsa8Oqc= X-Google-Smtp-Source: APXvYqxGQLvEEq9Bw5cGu/g+z1lU6DKGIXx5lITV7jvGGA3F7NUD8sMVOricW6alLayBL40Ej8RjrPW6sOGiT20GTT8= X-Received: by 2002:ac8:709a:: with SMTP id y26mr17342918qto.304.1579461760639; Sun, 19 Jan 2020 11:22:40 -0800 (PST) MIME-Version: 1.0 References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <3140.1579364674@localhost> <15967.1579382030@localhost> <24181.1579453158@localhost> In-Reply-To: <24181.1579453158@localhost> From: "Markku-Juhani O. Saarinen" Date: Sun, 19 Jan 2020 19:22:29 +0000 Message-ID: To: Michael Richardson Cc: Eric Rescorla , IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000002df303059c83196f" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 19:22:44 -0000 --0000000000002df303059c83196f Content-Type: text/plain; charset="UTF-8" On Sun, Jan 19, 2020 at 4:59 PM Michael Richardson wrote: > Eric Rescorla wrote: > mcr> No, it involves two sets of signatures. > mcr> The traditional set and the new, yet-to-be-precisely-defined set. > > > Yes, but I had understood these tbe encoded on the wire as if they > > were a new signature algorithm, with the result that such a > > certificate would not be verifiable by an existing client. > > > Perhaps we should resolve this question first. > > I believe that one proposal was to define a new signature type: > RSA -> F { RSA, PQ } > ECDSA -> G { ECDSA, PQ } > > and then, as you say, that would not interoperate at all. > > But, I think that another proposal is to introduce the additional > signatures > and related book-keeping as extensions, without disrupting the current > signature mechanisms. > Hi, As was noted when this draft was introduced, that PQ-in-extension mechanism is patented and Isara has indicated to IETF that will not allow it to be used royalty-free. See their IPR disclosure: https://datatracker.ietf.org/ipr/3287/ That tech is out there marketplace and will probably remain proprietary -- see e.g. DigiCert ( https://docs.digicert.com/certificate-tools/post-quantum-cryptography/pqc-toolkit-setup-guide/ ). The theory was discussed in "Transitioning to a Quantum-Resistant Public Key Infrastructure" ( PQCrypto 2017, https://eprint.iacr.org/2017/460.pdf ) which is related to the OQS implementation that works with OpenSSL and TLS ( https://github.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_1_1-stable ). There's also a separate Java implementation documented in "X.509-Compliant Hybrid Certificates for the Post-Quantum Transition" ( https://www.theoj.org/joss-papers/joss.01606/10.21105.joss.01606.pdf ). However the Isara-supported qTesla algorithm discussed in that report has had some problems and I'm not sure of its current status ( https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/round-2/official-comments/qTESLA-round2-official-comment.pdf ). Their customers are happy if they had a hybrid fall-back because it was already being shipped out. The OQS implementation seems to currently treat hybrid keys and signatures simply as OCTET STRING blobs and assigns an arbitrary OID for each such pair; I got 1.3.9999.2.2 for a p256_dilithium2 cert I just created. They emphasize that this is research code and not for production; the OID is of course not valid and the key/signature format is not properly documented as far as I know. This kind of solution would require n*m OIDs -- perhaps this is manageable, perhaps not -- the number of ciphersuites we used to have in TLS is an indication that things may get out of hand, especially if we further consider different hash functions used for signatures. Anyway, the additional ASN.1 structure bytes introduced by the draft would essentially document the structure of such blobs and put them under a single and/or a small number of OIDs. (Correct me if I'm wrong.) It would seem that the question of hash functions used in conjunction with the signature algorithms, and how to identify those, needs to be figured out. It may be reasonable to use SHA3 also in conjunction with the classical RSA/ECC sigs here ? Ultimaco also has a commercial toolkit ( https://hsm.utimaco.com/solutions/applications/post-quantum-crypto-agility/ ) but I'm not 100% which one they're using. It probably interoperates with the OQS kit at some level since they've worked with Microsoft to get Picnic (Microsoft's PQ signature proposal) to work with it. This in turn is used e.g. with Microsoft's PQ VPN ( for details of cert generation, see https://github.com/microsoft/PQCrypto-VPN/blob/master/openvpn/config/picnic-pki.md ). Sorry if I left someone out. There have been PQ X.509 trials at least for 5 years (strongSwan had Bliss in 2015 -- https://wiki.strongswan.org/projects/strongswan/wiki/Bliss ) but no effort on serious interop as I am aware. Cheers, - markku Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. --0000000000002df303059c83196f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 19, 2020 at 4:59 PM Michael R= ichardson <mcr+ietf@sandelman= .ca> wrote:
Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 mcr> No, it involves two sets of signatures.
=C2=A0 =C2=A0 mcr> The traditional set and the new, yet-to-be-precisely-= defined set.

=C2=A0 =C2=A0 > Yes, but I had understood these tbe encoded on the wire = as if they
=C2=A0 =C2=A0 > were a new signature algorithm, with the result that suc= h a
=C2=A0 =C2=A0 > certificate would not be verifiable by an existing clien= t.

=C2=A0 =C2=A0 > Perhaps we should resolve this question first.

I believe that one proposal was to define a new signature type:
=C2=A0 RSA=C2=A0 =C2=A0-> F { RSA, PQ }
=C2=A0 ECDSA -> G { ECDSA, PQ }

and then, as you say, that would not interoperate at all.

But, I think that another proposal is to introduce the additional signature= s
and related book-keeping as extensions, without disrupting the current
signature mechanisms.

Hi,

As was note= d when this draft was introduced,=C2=A0that PQ-in-extension mechanism is pa= tented and Isara has indicated to IETF that will not allow it to be used ro= yalty-free. See their IPR=C2=A0 disclosure:=C2=A0https://datatracker.ietf.org/ipr/3287/=C2=A0 = =C2=A0That tech is out there marketplace and will probably remain proprieta= ry -- see e.g. DigiCert (=C2=A0https://docs= .digicert.com/certificate-tools/post-quantum-cryptography/pqc-toolkit-setup= -guide/=C2=A0).=C2=A0

The theory wa= s discussed in "Transitioning to a Quantum-Resistant Public Key Infras= tructure" ( PQCrypto 2017,=C2=A0https://eprint.iacr.org/2017/460.pdf=C2=A0) which is related= to the OQS implementation that works with OpenSSL and TLS (=C2=A0https://github.com/open-quantum-safe/openssl/tree/OQS-OpenSSL_1_1_1-st= able=C2=A0).=C2=A0

There's also= a separate Java implementation=C2=A0documented in "X.509-Compliant Hy= brid Certificates for the Post-Quantum Transition" (=C2=A0https:= //www.theoj.org/joss-papers/joss.01606/10.21105.joss.01606.pdf=C2=A0=C2= =A0). However the Isara-supported qTesla algorithm discussed in that report= has had some problems and I'm not sure of its current status (=C2=A0h= ttps://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/document= s/round-2/official-comments/qTESLA-round2-official-comment.pdf=C2=A0). = Their customers are happy if they had a hybrid fall-back because it was alr= eady being shipped out.

The OQS impleme= ntation seems to currently treat hybrid keys and signatures simply as OCTET= STRING blobs and assigns an arbitrary OID for each such pair; I got 1.3.99= 99.2.2 for a =C2=A0p256_dilithium2 cert I just created. They emphasize that= this is research code and not for production; the OID is of course not val= id and the key/signature format is not properly documented as far as I know= .=C2=A0

This kind of solution would requi= re n*m OIDs -- perhaps this is manageable, perhaps not -- the number of cip= hersuites we used to have in TLS is an indication that things may get out o= f hand, especially if we further consider different hash functions used for= signatures. Anyway, the additional ASN.1 structure bytes introduced by the= draft would essentially document the structure of such blobs and put them = under a single and/or a small number of OIDs. (Correct me if I'm wrong.= )

It w= ould seem that the question of hash functions used in conjunction with the = signature algorithms, and how to identify those, needs to be figured out. I= t may be reasonable to use SHA3 also in conjunction with the classical RSA/= ECC sigs here ?=C2=A0

Ultimac= o=C2=A0also has a commercial toolkit (=C2=A0https://hsm.utimac= o.com/solutions/applications/post-quantum-crypto-agility/=C2=A0) but I&= #39;m not 100% which one they're using. It probably interoperates with = the OQS kit at some level since they've worked with Microsoft to get Pi= cnic (Microsoft's PQ signature proposal) to work with it. This in turn = is used e.g. with Microsoft's PQ VPN ( for details of cert generation, = see=C2=A0https://github.com/microsoft/PQCrypto-VPN/blob= /master/openvpn/config/picnic-pki.md=C2=A0).

Sorry if I left someone out. There have been PQ X.509 trials at l= east for 5 years (strongSwan=C2=A0had Bliss in 2015 --=C2=A0https://wiki.strong= swan.org/projects/strongswan/wiki/Bliss=C2=A0) but no effort on serious= interop as I am aware.

Cheers,
- markku

Dr. Markku-Juhani O.= Saarinen <mjos@p= qshield.com> PQShield, Oxford UK.
--0000000000002df303059c83196f-- From nobody Mon Jan 20 05:12:51 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2E012011C for ; Mon, 20 Jan 2020 05:12:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SctgO03QHQv4 for ; Mon, 20 Jan 2020 05:12:44 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0A7120090 for ; Mon, 20 Jan 2020 05:12:43 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id y4so33786817ljj.9 for ; Mon, 20 Jan 2020 05:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=otvvvWDPyrN/+pbWsPwoEuewDWcnjhCOJCEiIouQME0=; b=gmmWVz4t9slV0Tk+Ej980mjUNltbwqitWyD4GOC6MRW6Bfb/w/JOBktQNW2A3LpuNj /oH3Fi9o+FQiAHVtqZkJ+wtrylyZ36XP5JfPRC5xoJBxyYGhc8g+0IKmtZ8cmkXhvPao QVZA0U+yXRyerCrX3ZMatESQ3hRIdHldNzBaT2/Z5JAPXUneXOWnAO2jPpVrsYyuvKrr xcVGtrJBJo8DBzqfZTMfYfRGfGAcNkNBEV0u2g1Xde5VUG5NJE4MW7pjhFOBb3YVh/ED xvzoLRjDRffvJZ44QXMAe3AFRcQASpmp4teMHrJFX6pHDfz9C2yhMx1nF+vQPcXh9IgU 237g== 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=otvvvWDPyrN/+pbWsPwoEuewDWcnjhCOJCEiIouQME0=; b=Qhrh1MXLqOwkpRxXd5YJ3g6xAMyIwIYCCntKwHcJc3oDAh5L5bYcmDD7QWTq9+ykPH HbEIPoGrtaLXjHzyzVHKbs8e30BaPT2EI/6DVBsuTJDUuxS7JiIZZHK+3xgoC84n8GHH 9uG/aXjfAdO6OG2hRRGgtjriJcpRazSaBXiOpxoXdYTLqwGWWJf6mrf0x59q/qMkFDrZ Nc6CTx0CIuZNOmIndpy1BBaVZ5aWFWHpAg+Gn//qQisuJRGJz62ufSMeWoy8ZmRGB7He L5dXMSgAFSpyL4GYfHVASLZ9W/BBO7g3r5vhQryjEm/4P5QB3aeuyyj1BjlKoKMbdf9o 5XfQ== X-Gm-Message-State: APjAAAUGEe7/Il93lwX9PizpvCaRzkSoy8Fs/RZlpCRlfwNlfZxc4mlo JMgJlMLwLhojYHj9hnPGkLdW6xnljQAO9+KIwR9aMQ== X-Google-Smtp-Source: APXvYqwzPwwSL69FtVhEVn4xHUh0oTt7HCvIdfiAHcoFwczajTv13lHPRBghgSaSouYl7NHSTdWwaFs+vLjW780bemI= X-Received: by 2002:a2e:9510:: with SMTP id f16mr13568938ljh.249.1579525962084; Mon, 20 Jan 2020 05:12:42 -0800 (PST) MIME-Version: 1.0 References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <3140.1579364674@localhost> <15967.1579382030@localhost> <24181.1579453158@localhost> In-Reply-To: From: Eric Rescorla Date: Mon, 20 Jan 2020 05:12:04 -0800 Message-ID: To: "Markku-Juhani O. Saarinen" Cc: Michael Richardson , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000e24378059c920bd7" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 13:12:50 -0000 --000000000000e24378059c920bd7 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 19, 2020 at 11:22 AM Markku-Juhani O. Saarinen < mjos@pqshield.com> wrote: > On Sun, Jan 19, 2020 at 4:59 PM Michael Richardson > wrote: hybrid fall-back because it was already being shipped out. > > The OQS implementation seems to currently treat hybrid keys and signatures > simply as OCTET STRING blobs and assigns an arbitrary OID for each such > pair; I got 1.3.9999.2.2 for a p256_dilithium2 cert I just created. They > emphasize that this is research code and not for production; the OID is of > course not valid and the key/signature format is not properly documented as > far as I know. > > This kind of solution would require n*m OIDs -- perhaps this is > manageable, perhaps not -- the number of ciphersuites we used to have in > TLS is an indication that things may get out of hand, especially if we > further consider different hash functions used for signatures. Anyway, the > additional ASN.1 structure bytes introduced by the draft would essentially > document the structure of such blobs and put them under a single and/or a > small number of OIDs. (Correct me if I'm wrong.) > It's not clear to me that this level of complexity is required. At least on the Web, each algorithm would need to be individually considered by CABF and the browser vendors, so having a lot of flexibility here isn't that much of an asset, and having multiple tiers of parameters is not great. So, absent some evidence that we need this level of flexibility, I tend to think the one-oid-per-combo approach is fine. It might still be worth having an RFC which defined how to mint new oids, but that need not have complex on-the-wire internal structure. -Ekr --000000000000e24378059c920bd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 19, 2020 at 11:22 AM Mark= ku-Juhani O. Saarinen <mjos@pqshiel= d.com> wrote:
On Sun, Jan 19, 2020 at 4:59 PM Mich= ael Richardson <mcr+ietf@sandelman.ca> wrote:=C2=A0hybrid fall-back because it = was already being shipped out.
<= br>The OQS implementation seems to currently treat hybrid keys and signatur= es simply as OCTET STRING blobs and assigns an arbitrary OID for each such = pair; I got 1.3.9999.2.2 for a =C2=A0p256_dilithium2 cert I just created. T= hey emphasize that this is research code and not for production; the OID is= of course not valid and the key/signature format is not properly documente= d as far as I know.=C2=A0

This kind of so= lution would require n*m OIDs -- perhaps this is manageable, perhaps not --= the number of ciphersuites we used to have in TLS is an indication that th= ings may get out of hand, especially if we further consider different hash = functions used for signatures. Anyway, the additional ASN.1 structure bytes= introduced by the draft would essentially document the structure of such b= lobs and put them under a single and/or a small number of OIDs. (Correct me= if I'm wrong.)

It= 9;s not clear to me that this level of complexity is required. At least on = the Web, each algorithm would need to be individually considered by CABF an= d the browser vendors, so having a lot of flexibility here isn't that m= uch of an asset, and having multiple tiers of parameters is not great. So, = absent some evidence that we need this level of flexibility, I tend to thin= k the one-oid-per-combo approach is fine.

It might= still be worth having an RFC which defined how to mint new oids, but that = need not have complex on-the-wire internal structure.

-Ekr


--000000000000e24378059c920bd7-- From nobody Mon Jan 20 05:53:38 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647A612013B for ; Mon, 20 Jan 2020 05:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 huoXz3qgLunZ for ; Mon, 20 Jan 2020 05:53:31 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 DB250120129 for ; Mon, 20 Jan 2020 05:53:30 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id z26so3470812lfg.13 for ; Mon, 20 Jan 2020 05:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ngEeBN964nK6cRekveLIXJwb6SoK21+cYUDJdPOpHI=; b=BoqmpVbbM4pi5vaX/zji4U5cUqucoQh8Dl/cdg1uqNB5Kk1j1Y4iB5GDMC3zjgTTto sF6BKC2ewttQY02N53PQoVN5BoM2KSiIDqm55fl/8ZS+yhdg1aFh8kIjhe0Ij7hy/eyI FZzOeWf5WmNarmRPHjtLJ+8RAVqjS0HQ90CGOOR5Y71T86WccbRLeDQIbFtpLNYtqvEM xBv88Br56d+JwDTRAnKuvg2vFW2Fc4AbAPygPG46M7AqB2i3k8i6Lt2W5L3AWYryiN8H qDSemqgBqvBITIPjQFx0T3HYOluhC84Tvk5yqt/BeJjnKpCGlljcx95FEfq2Oz1Q9FoE PP+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0ngEeBN964nK6cRekveLIXJwb6SoK21+cYUDJdPOpHI=; b=nWjXoWV2hFOKXOdwzDnY3HTGDF0rz2WxfzexUyr3eltRgyfq4Vcnv4+rE8JWdIw+HD Gn0GnZPPIiccJfIIVaGK49f+asRD41lfT8AL84bY95BWBWdga3PnfSngbWip8ctUIGIH tEnZrWYU0pZHMsQDdDx+SiMKVMz0hUNky5hfcifY4gKaozVLRI4RYtizzqfg1w7zHsSY dJYOhjX9SmI0JBVeo+rR5lSu5EbbRulf+N4EbTjXunodZb0DQzkPz4a7YceVbccJ9PgM R3z6291qsm8jCzTTVZO3vN+i2vFxdRlinvGaours80Zkhe0NcvQFAP7u7V4h3GzGWjZK B4rg== X-Gm-Message-State: APjAAAVoBCCvjb0BfIUHtQ0t53zVWidI2Qv49UUNEcN974TWdL1L98xz bDi6L1UmjR3KE6Jct0DgYiG8k5sukw09mt1/7VhwzLFrTp2C3BgoXx8UW1gNosevVh1PmuY9OZ6 rQSlbWmluog4NmQHBkgFuiA== X-Google-Smtp-Source: APXvYqzSKkbIkLtc+s559GGHZLptPbbvSZrI2uSr8wTF7yYKpSgg22Weim4+iNrPRJ6SPsfT35EIm29gUdNxwnxdP/c= X-Received: by 2002:ac2:523c:: with SMTP id i28mr1594804lfl.104.1579528409126; Mon, 20 Jan 2020 05:53:29 -0800 (PST) MIME-Version: 1.0 References: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> <22451.1579452735@localhost> In-Reply-To: <22451.1579452735@localhost> From: Brian Campbell Date: Mon, 20 Jan 2020 06:53:02 -0700 Message-ID: To: Michael Richardson Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bd3174059c929d75" Archived-At: Subject: Re: [Secdispatch] [saag] SECDISPATCH WG Summary from IETF 106 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 13:53:37 -0000 --000000000000bd3174059c929d75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Michael for the read of the document and feedback. Some responses are inline. On Sun, Jan 19, 2020 at 9:52 AM Michael Richardson wrote: > > Thanks for this document. > I think it is useful and important work. > {"something-something" sounds like something that Winnie the Pooh would > ask to > eat for lunch} > Via email exchange it's not entirely clear whether that's a compliment or a criticism or just an observation. It was meant as a nod to the header name chosen in the example on slide 4 of https://datatracker.ietf.org/meeting/106/materials/slides-106-secdispatch-s= ecuring-protocols-between-proxies-and-backend-http-servers-00 which was there as a semi-humorous placeholder of a name to indicate that the name is both important and unimportant at the same time. > draft-ietf-anima-bootstraping-keyinfra (aka BRSKI) makes use of TLS Clien= t > Certificates in the Registrar. > I have a document on operational considerations for Registrars, > draft-richardson-anima-registrar-considerations > and I've added your document as reference. > > In section 1, you may wish to reference: > https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface > > although I can't find a section in > https://www.python.org/dev/peps/pep-3333/ > that describes the Client Certificate variable. I use "SSL_CLIENT_CERT" > and more recently, "rack.peer_cert" in my code. > AFAIK, those are de facto names originating out of defaults or documentation from reverse proxy implementations that allow for similar behaviour with respect to the client cert. Apache mod_ssl and Ruby thin respectively I think. For better or worse, I tried to choose a name that's meaningful and shortish. And one that doesn't look like it came from the default documentation of some popular web server. ** I would like to have access to the entire client certificate *chain* ** > Not just the End-Entity certificate. > > If any internal trust anchors were used to validate the chain, I also wou= ld > prefer to receive them as well. > > Finally, I need to be able to configure the reverse proxy to do the TLS > operation on the assumption that the certificate validates, even if the > reverse proxy does not know how to validate the certificate chain itself. > > I need, therefore, to know if the certificate chain was validated, or not= . > In writing up this initial draft, I waffled about whether or not to include intermediate signers and/or the whole chain. Although I landed on only passing the leaf certificate, this is certainly something that's up for discussion should this document find a home where it can be worked on and progressed. > You write: > Forward proxies and other intermediaries MUST NOT add the Client-Cert > header to requests. > > but, the reverse proxy can not control what is sent to it, and you > shouldn't > try to write normative language there. > True, the reverse proxy can not control what is sent to it. But it's meant to be normative language towards other forward proxies and other intermediaries to say that they can't/shouldn't be adding this thing. Which seems legit (and something I'm told is supposed to be covered for registry requests on header fields). Perhaps that text can be moved or adjusted in a way that makes the distinction more clear. > > You already handle this: > 2) Any occurrence of the Client-Cert header in the original incoming > request MUST be removed or overwritten before forwarding the request= . > > and leave it like that, maybe emphasis this. > Maybe reverse proxies SHOULD reject requests that have a Client-Cert head= er > in them, period? > That's certainly an option. I suppose there are tradeoffs between rejecting vs. cleaning such requests. Maybe a MAY would be appropriate for something like that so as to give the proxy the option. Again, that's something that could be fleshed out in discussions if this thing finds a home. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000bd3174059c929d75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Michael for the read of the document and feedb= ack. Some responses are inline.

On Sun, Jan 19, 2020 at 9:52 AM Michael= Richardson <mcr+ietf@sandelman.ca> wrote:

Thanks for this document.
I think it is useful and important work.
{"something-something" sounds like something that Winnie the Pooh= would ask to
eat for lunch}

Via email exchange it= 9;s not entirely clear whether that's a compliment or a criticism or ju= st an observation.

It was meant as a nod to t= he header name chosen in the example on slide 4 of https:/= /datatracker.ietf.org/meeting/106/materials/slides-106-secdispatch-securing= -protocols-between-proxies-and-backend-http-servers-00 which was there = as a semi-humorous placeholder of a name to indicate that the name is both = important and unimportant at the same time.


draft-ietf-anima-bootstraping-keyinfra (aka BRSKI) makes use of TLS Client<= br> Certificates in the Registrar.
I have a document on operational considerations for Registrars,
=C2=A0 draft-richardson-anima-registrar-considerations
and I've added your document as reference.

In section 1, you may wish to reference:
=C2=A0 =C2=A0https://en.wikipedia.org/wiki= /Web_Server_Gateway_Interface

although I can't find a section in https://www.python.o= rg/dev/peps/pep-3333/
that describes the Client Certificate variable.=C2=A0 I use "SSL_CLIEN= T_CERT"
and more recently, "rack.peer_cert" in my code.
<= div>
AFAIK, those are de facto names originating out of defau= lts or documentation from reverse proxy implementations that allow for simi= lar behaviour with respect to the client cert. Apache mod_ssl and Ruby thin= respectively I think.

For better or worse, I= tried to choose a name that's meaningful and shortish. And one that do= esn't look like it came from the default documentation of some popular = web server.
=C2=A0

** I would like to have access to the entire client certificate *chain* **<= br> Not just the End-Entity certificate.

If any internal trust anchors were used to validate the chain, I also would=
prefer to receive them as well.

Finally, I need to be able to configure the reverse proxy to do the TLS
operation on the assumption that the certificate validates, even if the
reverse proxy does not know how to validate the certificate chain itself.
I need, therefore, to know if the certificate chain was validated, or not.<= br>

In writing up this initial draft, I waf= fled about whether or not to include intermediate signers and/or the whole = chain. Although I landed on only passing the leaf certificate, this is cert= ainly something that's up for discussion should this document find a ho= me where it can be worked on and progressed.

= =C2=A0
You write:
=C2=A0 Forward proxies and other intermediaries MUST NOT add the Client-Cer= t header to requests.

but, the reverse proxy can not control what is sent to it, and you shouldn&= #39;t
try to write normative language there.

= True, the reverse proxy can not control what is sent to it. But it's me= ant to be normative language towards other forward proxies and other interm= ediaries to say that they can't/shouldn't be adding this thing. Whi= ch seems legit (and something I'm told is supposed to be covered for re= gistry requests on header fields). Perhaps that text can be moved or adjust= ed in a way that makes the distinction more clear.

=C2=A0

You already handle this:
=C2=A0 2) Any occurrence of the Client-Cert header in the original incoming=
=C2=A0 =C2=A0 =C2=A0request MUST be removed or overwritten before forwardin= g the request.

and leave it like that, maybe emphasis this.
Maybe reverse proxies SHOULD reject requests that have a Client-Cert header=
in them, period?

That's certainly a= n option. I suppose there are tradeoffs between rejecting vs. cleaning such= requests. Maybe a MAY would be appropriate for something like that so as t= o give the proxy the option. Again, that's something that could be fles= hed out in discussions if this thing finds a home.

=C2=A0

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




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000bd3174059c929d75-- From nobody Mon Jan 20 06:40:35 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB88F1200B7 for ; Mon, 20 Jan 2020 06:40:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pqshield-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7FRhX4hCuhc for ; Mon, 20 Jan 2020 06:40:27 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 43073120041 for ; Mon, 20 Jan 2020 06:40:27 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id w8so13393116qts.11 for ; Mon, 20 Jan 2020 06:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mNLJ+gmBPcKcXzRZFET842T42sHAD21sLULZnObxKEQ=; b=Sq9TX+KaWUM1o71C1OIonmiD8Ye3KNlLSCmVO3aUf69bzhBCKDl/gjSIBekPpnEgpe d6dJj2FXB581kiECEQJdDGHilJJYINSKnBGZth9Tw5QPVrqDjp6rcA3OhAovvIBgX82X xSh8O3/W35bZfuON6/M3x18DHhNx7+dqSPqj+FehtmRkkNld/zzxkBOvOnb+u9zLgaxC rKtA90aKjvwd3BAhZMKoH8hDF5HfEdxBGzi+wlizMvknZY+KNnfXNvif0+KIDO40JICY e1fJeIJGHMnZ8EsrEWcjWCCjRXxsPulmXOQPw7xMEmY7UEjMCXcGPOAs7UTNeCaspiQg MfKg== 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=mNLJ+gmBPcKcXzRZFET842T42sHAD21sLULZnObxKEQ=; b=Cq+mryMaEw7Sog7bHumINB7t1joUB8UYP4ZRHuCVQ7u+pZrqeFuP/V0q8tddmxX/zF fU9st6lIxlfPVnmkX+YLtJJ8Nk0ifpzkM8pMiZ1HGgIElOTkWoF2GRCFxsShILf56N4v woBdEs5QsNWnr+/25T1tGUs9CgUcpkPhuDa4EHUy9fqjtB/H1fL9OMsiqU8xFOzfdafO e5pQfq+dBnWPt497VI99K0v6j4qg6kPazF4ZzwgZ8Zd6Rfpsw45Zx5K4rxDwRAZ39sF2 LV+C1xixAr8QzxwA0r2ojGmosLVeJIOY4DhfTeXYlchaXTG8aJq1W7LELfYQSRxQnSkK Mt8g== X-Gm-Message-State: APjAAAUsl9OMOlKWndo4nIos3wenH2Kkib7cuEjF3mAMu3sPV5AM2dBx LvBnaA7nzyJe9/P8DvyouPMp3liN5Y6eTfB6Xrn/nw== X-Google-Smtp-Source: APXvYqxE+SNhuohNnbBSJ4PtDLfaG3W5WIr1uCdWzTKTBO02oVRBAWOY31Rr/YtikWg1U2DYlhSBbeQiOBk+z6CmUb8= X-Received: by 2002:ac8:21ec:: with SMTP id 41mr21319185qtz.242.1579531226305; Mon, 20 Jan 2020 06:40:26 -0800 (PST) MIME-Version: 1.0 References: <70b221bb-bc39-52cc-f9e0-a84261afe473@cs.tcd.ie> <09B0CA53-BAAF-4139-8179-2A70ADE58632@isara.com> <3f9de00e-85ad-48ed-ba97-e1b5418e3867@cs.tcd.ie> <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <3140.1579364674@localhost> <15967.1579382030@localhost> <24181.1579453158@localhost> In-Reply-To: From: "Markku-Juhani O. Saarinen" Date: Mon, 20 Jan 2020 14:40:15 +0000 Message-ID: To: Eric Rescorla Cc: Michael Richardson , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000a7e823059c934553" Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 14:40:34 -0000 --000000000000a7e823059c934553 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 20, 2020 at 1:12 PM Eric Rescorla wrote: > The OQS implementation seems to currently treat hybrid keys and signatures >> simply as OCTET STRING blobs and assigns an arbitrary OID for each such >> pair; I got 1.3.9999.2.2 for a p256_dilithium2 cert I just created. They >> emphasize that this is research code and not for production; the OID is of >> course not valid and the key/signature format is not properly documented as >> far as I know. >> >> This kind of solution would require n*m OIDs -- perhaps this is >> manageable, perhaps not -- the number of ciphersuites we used to have in >> TLS is an indication that things may get out of hand, especially if we >> further consider different hash functions used for signatures. Anyway, the >> additional ASN.1 structure bytes introduced by the draft would essentially >> document the structure of such blobs and put them under a single and/or a >> small number of OIDs. (Correct me if I'm wrong.) >> > > It's not clear to me that this level of complexity is required. At least > on the Web, each algorithm would need to be individually considered by CABF > and the browser vendors, so having a lot of flexibility here isn't that > much of an asset, and having multiple tiers of parameters is not great. So, > absent some evidence that we need this level of flexibility, I tend to > think the one-oid-per-combo approach is fine. > > It might still be worth having an RFC which defined how to mint new oids, > but that need not have complex on-the-wire internal structure. > Hi, I'd be fine with either way (on the hardware firmware front) and colleagues working on the TLS code comment that they don't see much difference in implementation complexity either. The additional structure is certainly helpful in the experimentation phase and is there to make things easier and more robust, not harder. We would just like to have at least one open specification for this thing, and preferably not more than one. Basically the only additional structure carried here is the OIDs for the key and signature components. Their lengths need to be encoded anyway, so some structure is needed. The PQC binary formats don't define what kind of keys/signatures they are or how long they are. So I see the advantage of having that information available at least somewhere. Combining several OIDS directly into a single OID, or having to go through IANA to get a one or two dozen new OIDs for each variant or hash function combination seems clumsy. A couple of additional technical points: - The reason why I mentioned SHA3/SHAKE for RSA and ECC is that this would seem to allow message hashing to be performed only once, rather than twice (at least for Dilithium and Falcon). - We don't see this as being as widely used for TLS server authentication as for smart cards, secure elements and similar applications that can't just switch or negotiate certificate chains on the fly. I work on the hardware side myself and especially there we have additional considerations such as hardcoded cert chains and FIPS certification, which is currently only available for the hybrid case. I wouldn't want to leave the issuance of OIDs for this purpose at the mercy of TLS folks, which is just one of many applications of this format. Cheers, - markku Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. --000000000000a7e823059c934553 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 20, 2020 at 1:12 PM Eric Resc= orla <ekr@rtfm.com> wrote:
The OQS= implementation seems to currently treat hybrid keys and signatures simply = as OCTET STRING blobs and assigns an arbitrary OID for each such pair; I go= t 1.3.9999.2.2 for a =C2=A0p256_dilithium2 cert I just created. They emphas= ize that this is research code and not for production; the OID is of course= not valid and the key/signature format is not properly documented as far a= s I know.=C2=A0

This kind of solution wou= ld require n*m OIDs -- perhaps this is manageable, perhaps not -- the numbe= r of ciphersuites we used to have in TLS is an indication that things may g= et out of hand, especially if we further consider different hash functions = used for signatures. Anyway, the additional ASN.1 structure bytes introduce= d by the draft would essentially document the structure of such blobs and p= ut them under a single and/or a small number of OIDs. (Correct me if I'= m wrong.)

It's not cl= ear to me that this level of complexity is required. At least on the Web, e= ach algorithm would need to be individually considered by CABF and the brow= ser vendors, so having a lot of flexibility here isn't that much of an = asset, and having multiple tiers of parameters is not great. So, absent som= e evidence that we need this level of flexibility, I tend to think the one-= oid-per-combo approach is fine.

It might still be = worth having an RFC which defined how to mint new oids, but that need not h= ave complex on-the-wire internal structure.

Hi,

I'd = be fine with either way (on the hardware firmware front) and colleagues wor= king on the TLS code comment that they don't see much difference in imp= lementation complexity either. The additional structure is certainly helpfu= l in the experimentation phase and is there to make things easier and more = robust, not harder. We would just like to have at least one open specificat= ion for this thing, and preferably not more than one.

Basically the only a= dditional structure carried here is the OIDs for the key and signature comp= onents. Their lengths need to be encoded anyway, so some structure is neede= d.

The PQC binary formats don't define what ki= nd of keys/signatures they are or how long they are. So I see the advantage= of having that information available at least somewhere. Combining several= OIDS directly into a single OID, or having to go through IANA to get a one= or two dozen new OIDs for each variant or hash function combination seems = clumsy.

A couple of additional technical points:
- The reason why I mentioned SHA3/SHAKE for RSA and ECC is that th= is would seem to allow message hashing to be performed only once, rather th= an twice (at least for Dilithium and Falcon).
=C2=A0- We don'= t see this as being as widely used for TLS server authentication as for sma= rt cards, secure elements and similar applications that can't just swit= ch or negotiate certificate chains on the fly. I work on the hardware side = myself and especially there we have additional considerations such as hardc= oded cert chains and FIPS certification, which is currently only available = for the hybrid case. I wouldn't want to leave the issuance of OIDs for = this purpose at the mercy of TLS folks, which is just one of many applicati= ons of this format.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK.
--000000000000a7e823059c934553-- From nobody Mon Jan 20 09:18:40 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730BA1209E2 for ; Mon, 20 Jan 2020 09:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83Sl4CP7Jy53 for ; Mon, 20 Jan 2020 09:18:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91E61209DB for ; Mon, 20 Jan 2020 09:18:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5EA993897E; Mon, 20 Jan 2020 12:18:00 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 236A05F5; Mon, 20 Jan 2020 12:18:31 -0500 (EST) From: Michael Richardson To: Brian Campbell cc: "secdispatch\@ietf.org" In-Reply-To: References: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> <22451.1579452735@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] [saag] SECDISPATCH WG Summary from IETF 106 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 17:18:39 -0000 --=-=-= Content-Type: text/plain bc> Via email exchange it's not entirely clear whether that's a compliment or a bc> criticism or just an observation. compliment. bc> It was meant as a nod to the header name chosen in the example on slide 4 bc> of Ah! >> draft-ietf-anima-bootstraping-keyinfra (aka BRSKI) makes use of TLS Client >> Certificates in the Registrar. >> I have a document on operational considerations for Registrars, >> draft-richardson-anima-registrar-considerations >> and I've added your document as reference. >> >> In section 1, you may wish to reference: >> https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface >> >> although I can't find a section in >> https://www.python.org/dev/peps/pep-3333/ >> that describes the Client Certificate variable. I use "SSL_CLIENT_CERT" >> and more recently, "rack.peer_cert" in my code. >> bc> AFAIK, those are de facto names originating out of defaults or bc> documentation from reverse proxy implementations that allow for similar bc> behaviour with respect to the client cert. Apache mod_ssl and Ruby thin bc> respectively I think. bc> For better or worse, I tried to choose a name that's meaningful and bc> shortish. And one that doesn't look like it came from the default bc> documentation of some popular web server. My point is to a) point to de-facto names which are currently being used to demonstrate the need for a standard. b) indicate if the contents are the same or different. mcr> ** I would like to have access to the entire client certificate *chain* ** >> Not just the End-Entity certificate. >> >> If any internal trust anchors were used to validate the chain, I also would >> prefer to receive them as well. >> >> Finally, I need to be able to configure the reverse proxy to do the TLS >> operation on the assumption that the certificate validates, even if the >> reverse proxy does not know how to validate the certificate chain itself. >> >> I need, therefore, to know if the certificate chain was validated, or not. >> bc> In writing up this initial draft, I waffled about whether or not to include bc> intermediate signers and/or the whole chain. Although I landed on only bc> passing the leaf certificate, this is certainly something that's up for bc> discussion should this document find a home where it can be worked on and bc> progressed. good, we agree. Isn't httpbis the obvious WG here? It could be that we should have two headers. One for the EE, and one (or many?) for the chain. >> You write: >> Forward proxies and other intermediaries MUST NOT add the Client-Cert >> header to requests. >> >> but, the reverse proxy can not control what is sent to it, and you >> shouldn't >> try to write normative language there. >> bc> True, the reverse proxy can not control what is sent to it. But it's meant bc> to be normative language towards other forward proxies and other bc> intermediaries to say that they can't/shouldn't be adding this thing. Which bc> seems legit (and something I'm told is supposed to be covered for registry bc> requests on header fields). Perhaps that text can be moved or adjusted in a bc> way that makes the distinction more clear. Sure. I'm saying no normative language about another entity. The normative language should say that reverse proxies MUST remove the header when coming in. >> You already handle this: >> 2) Any occurrence of the Client-Cert header in the original incoming >> request MUST be removed or overwritten before forwarding the request. >> >> and leave it like that, maybe emphasis this. >> Maybe reverse proxies SHOULD reject requests that have a Client-Cert header >> in them, period? >> bc> That's certainly an option. I suppose there are tradeoffs between rejecting bc> vs. cleaning such requests. Maybe a MAY would be appropriate for something bc> like that so as to give the proxy the option. Again, that's something that bc> could be fleshed out in discussions if this thing finds a home. It seems like a request that arrives with Client-Cert in it is at best misconfiguration, and at worse an attack. It can't be legitimate. I think that being tolerant here does not benefit anyone. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4l4OYACgkQgItw+93Q 3WU2hgf+IiOs66lyT9W9eUppfVn7ddOFAT/Xl5f3I/9v5Ou6mnDis0n/4HAAFg5n BYfXumRzJ14T7rwVBIMzpguhsRal9LhPRtSevX9jPWE3HVgmi0GcTQ+kdPZpNikA pR7PzJYkbPgB5bjIjwUcLh6KYl9byfV77iOt/watLXmORHe5JQLhYwUQgjeGSiei XEGCQOE8KJzYOHzCCPS/DA2i3rVULa60Ph/OSKL5D0r+/FUCpPxAZJKMMmospFQx LqJkyblCbm25YrzMzec0XV0OejWaUCV3OAJwV+BX+o0VnAzr6m3HRc+hkKQP2zcL ARySiujioiG6aEt6Yhv+GLsjuiJjtQ== =806q -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 21 10:18:37 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851CA12099C; Tue, 21 Jan 2020 10:18:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NzdGvcKQDFT; Tue, 21 Jan 2020 10:18:26 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B09212097F; Tue, 21 Jan 2020 10:18:26 -0800 (PST) IronPort-SDR: RcVWFl/HC4li5abS2M5cmz3y65SRLSv7Wl5tSilJH21Yi1l4c3tqPucBD42mpm0SVQLM6zzTWB XycSev/y3axw== X-IronPort-AV: E=Sophos;i="5.70,346,1574143200"; d="scan'208,217";a="7897255" Received: from pmspex02.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.30]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 21 Jan 2020 12:18:24 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 21 Jan 2020 12:18:24 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 21 Jan 2020 12:18:23 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oL3hJaGUdVn1IP9eIbeoM7v28mHtlMmmSr3msUiBHaM0ydH5PF0Rdo6yB8+DZPYSDFN3U1eiX6LNVBEFbkjWrynsrlwzVvVLfLUWemwMQQK3e752tf94rrug5PGjJQobUTor4vbXbQBZuRVAOGj21jPjadHHUFF+3qtuV+Cztus036tgEd00piBUkmPA5nGuRfId3YRyLy6zWN7wOqyNdqIvpkcITKCPEGARfsQwTBDcQ8eo4jT2ShTSKTjTId169xgB1FgJymyK7H550VHHMlToTVWnpyhHGF0iJ9WS7QnxgEopCfwVATZQgyA8RuvfBx4YLBnbA833b3hHrpjJ5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J772LbiZsnIUsrsUqgZQP5DiINRyr3GWklgfnKHzaT8=; b=Jl1hodAKz/kun1CW4EdQUNLAp4HVFxaxSmL6G7C7irpc2nf2rJWXJQ1MjWUGWspGP4cLJMAHvqtNeE39dEcqUjMDykDeIsRUI84EgtziZOkC7PJT8SvJ/Mtfexv1ChcBjkPJ5cmq6BZIEd2Gg/nB82cuvfzBsYXg4FQRQI0MoYqKIzHfF0V8rFRBYGffRudjMUXzdTugVs0LZQNBRNjbB9mH4t5SW97p+xEXx2nV4UAmGglcNSQdthUex/ECvuRj/nZ7JKn8rU69Mf/dsMf+DVhsHAcwVDfLBoKMUYH4AUP3Owb2pNUUdhDf3dG+Hye96Dq9LHsU1wsE23gU0JGh7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J772LbiZsnIUsrsUqgZQP5DiINRyr3GWklgfnKHzaT8=; b=fX4wVStCMeEYrGZr+oeb3IJIzsA7YfJA4kARsosS/CXAwaOYTq4Jlu8HM3NEDFjEzY1NeSckBUR8FHBPcMLkvSTUl0TIhhkAeH5gfZrcxdr7zaUQa8qSKBwH8jqMVkFbBbiUOw9fybiewby79BSFVB0pTLmToJhgo2W5ioYc1YQ= Received: from DM6PR11MB3883.namprd11.prod.outlook.com (10.255.61.32) by DM6PR11MB3995.namprd11.prod.outlook.com (10.255.61.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Tue, 21 Jan 2020 18:18:23 +0000 Received: from DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392]) by DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392%6]) with mapi id 15.20.2644.027; Tue, 21 Jan 2020 18:18:23 +0000 From: Mike Ounsworth To: Brian Campbell , "Francesca Palombini" CC: "secdispatch@ietf.org" , "saag@ietf.org" Thread-Topic: [EXTERNAL]Re: [Secdispatch] SECDISPATCH WG Summary from IETF 106 Thread-Index: AQHVn1vFDxHCv1ors0i+tXiIXiWbjqfvrqyAgAAb1cA= Date: Tue, 21 Jan 2020 18:18:23 +0000 Message-ID: References: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [70.76.144.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17fc2fef-d3ec-400d-127b-08d79e9e4d37 x-ms-traffictypediagnostic: DM6PR11MB3995: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(366004)(39860400002)(189003)(199004)(76116006)(66446008)(64756008)(66556008)(66476007)(66946007)(66574012)(71200400001)(110136005)(316002)(54906003)(55016002)(5660300002)(478600001)(21615005)(966005)(9686003)(52536014)(81156014)(2906002)(8676002)(8936002)(81166006)(7696005)(33656002)(6506007)(4326008)(26005)(186003)(53546011)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB3995; H:DM6PR11MB3883.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6Iy6cWK36QcMdw+2TOGDDPuOcGIAV+2Bc5REKfvP28FSJAI53twG1OmuUH/jqvQAJYoWRAifiTKXkA3lPcSqMn2RWfFX17Tpp2EqeTImai/pAzEoYjbenGoJ91z2KyB1vRVmfkPrYVjm02/Nh/4x/TItHECFiVKbzHHUg1+SqyC65i/+Fji2GtJaJTpZHMYme3MfyyaEp5yWXAvUewQJ678U8xsws2+hLj+ob/ydFbTtpWCo0D1PoQYRvV7M5icjdTkVphkzsVwHyZtUhf/w4RqPTj042l6yIOOB5sdBjRhDOjZZsaA3MFmhgr2V2vQ/3zvRQFZ3pgVF0XXCm3HwqKxibZJ3DCsa7kl02QTvqvAtRYT77/GxgNdr/yl9O+WdWwNgbqbcplzTBhSLobd2T9Q0opOFIc5ux51kNF9YbxfmzNtm7nnucv8Ta5V+gbIQ/A4RlhAmzC4jkc4x5kqHuENXMWDJ/Q8Q71VWiWjCULp6k3Lza7rqDti3uPvaRQNxi7KIiwQ0mE1rqJZz9pLPFQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3883B6A92EE8946978C6D7E69B0D0DM6PR11MB3883namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 17fc2fef-d3ec-400d-127b-08d79e9e4d37 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 18:18:23.2311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: STru4m9K9VmxL5NXKkzFGcJq+aGWdVdioAxrupcOTSJ2S9fOoZ7X2/Uzo7YFTN0ZQx8A7SuEd2VE4Qs2AdoFNATHB8teDBQkVjUO87lVJAifOCGo5mwk45IlfkQcOBpi X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3995 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: SECDISPATCH WG Summary from IETF 106 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 18:18:31 -0000 --_000_DM6PR11MB3883B6A92EE8946978C6D7E69B0D0DM6PR11MB3883namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoaXMgZWZmb3J0IQ0KDQpUaGUgbGFjayBvZiBzdWNoIGEgaGVhZGVyIGhhcyBi ZWVuIGEgcGFpbiBwb2ludCBmb3IgbWlncmF0aW5nIGFwcGxpY2F0aW9ucyB3aXRoIGNsaWVudC1j ZXJ0IGRyaXZlbiBhdXRoIG1lY2hhbmlzbXMgaW50byB0aGUgY2xvdWQuDQoNCi0tLQ0KTWlrZSBP dW5zd29ydGgNClNvZnR3YXJlIFNlY3VyaXR5IEFyY2hpdGVjdCwgRW50cnVzdCBEYXRhY2FyZA0K DQpGcm9tOiBTZWNkaXNwYXRjaCA8c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBKYW51YXJ5IDE3LCAyMDIwIDI6NDMgUE0NClRv OiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29t QGRtYXJjLmlldGYub3JnPg0KQ2M6IHNlY2Rpc3BhdGNoQGlldGYub3JnOyBzYWFnQGlldGYub3Jn DQpTdWJqZWN0OiBbRVhURVJOQUxdUmU6IFtTZWNkaXNwYXRjaF0gU0VDRElTUEFUQ0ggV0cgU3Vt bWFyeSBmcm9tIElFVEYgMTA2DQoNCldBUk5JTkc6IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBvdXRz aWRlIG9mIEVudHJ1c3QgRGF0YWNhcmQuDQpETyBOT1QgQ0xJQ0sgbGlua3Mgb3IgYXR0YWNobWVu dHMgdW5sZXNzIHlvdSB0cnVzdCB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNh ZmUuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXBvbG9naWVzIGZvbGtzLCBJ J20gcmVzcG9uc2libGUgZm9yIHRoZSBydXNoZWQgYW5kIGF3a3dhcmQgcHJlc2VudGF0aW9uIGFi b3V0IHJldmVyc2UgcHJveGllcyBhbmQgVExTIGNsaWVudCBjZXJ0aWZpY2F0ZXMgYXQgdGhlIHZl cnkgZW5kIG9mIHRoZSBTRUNESVNQQVRDSCBzZXNzaW9uIGluIFNpbmdhcG9yZSwgd2hpY2ggaXMg bWVudGlvbmVkIGJlbG93IHdpdGggIm5vIGRyYWZ0IHlldC0tPiBuZWVkcyBkcmFmdCIuIEl0IHRv b2sgbWUgYSBsaXR0bGUgd2hpbGUgdG8gZ2V0IHRocm91Z2ggdGhlIHdvcmsgYnV0IEknbSBoYXBw eSB0byBzaGFyZSB0aGF0IHRoZXJlIGlzIG5vdyBhbiBhY3R1YWwgZHJhZnQgYXZhaWxhYmxlLiBI ZXJlIGl0IGlzIGluIHRoZSBmYW5jeSBuZXcgSFRNTCBmb3JtYXQ6IGh0dHBzOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LWJkYy1zb21ldGhpbmctc29tZXRoaW5nLWNlcnRpZmljYXRlLTAxLmh0bWwg YXMgd2VsbCBhcyB0aGUgZ29vZCBvbCBzdGF0dXMgcGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYmRjLXNvbWV0aGluZy1zb21ldGhpbmctY2VydGlmaWNhdGUvDQoN Cg0KT24gVHVlLCBOb3YgMTksIDIwMTkgYXQgOTozNCBQTSBGcmFuY2VzY2EgUGFsb21iaW5pIDxm cmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KVGhlIFNFQ0RJU1BBVENIIFdH IG1ldCBvbiBUdWVzZGF5IE5vdmVtYmVyIDE5LiAgVGhlIGFnZW5kYSBpdGVtcyB3ZXJlIGRpc3Bh dGNoZWQgYXMgZm9sbG93czoNCg0KKDEpIFByb2JsZW0gc3RhdGVtZW50IGZvciBwb3N0LXF1YW50 dW0gbXVsdGktYWxnb3JpdGhtIFBLSSAoTWF4IFBhbGEpDQpkcmFmdHM6ICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wcS1wa2l4LXByb2JsZW0tc3RhdGVtZW50Lw0KICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1vdW5zd29ydGgtcHEt Y29tcG9zaXRlLXNpZ3MvDQotLT4gZGlzcGF0Y2ggdG8gTEFNUFMgV0cgKGNvbmZpcm0gb24gbWFp bGluZyBsaXN0KQ0KDQooMikgT0NTUHYyIC0gSW1wcm92aW5nIE9DU1AgUmVzcG9uc2VzIChNYXgg UGFsYSkNCkxBTVBTICYgUEtJWCBkaXNjdXNzaW9uczoNCkRyYWZ0OiAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXBhbGEtb2NzcHYyLTAwDQotLT4gY3JlYXRlIGEgQm9GIGZvciBz bWFsbCBmb2N1c2VkIFdHDQoNCigzKSBQcml2YWN5IFBhc3MgUHJvdG9jb2wgKE5pY2sgU3VsbGl2 YW4pDQpkcmFmdHM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXByaXZh Y3ktcGFzcy8NCi0tPiB3b3JrIG9uIGNoYXJ0ZXIgdGV4dCB0aGVuIEJvRiBmb3Igc21hbGwgZm9j dXNlZCBXRw0KDQooNCkgSFRUUCBSZXF1ZXN0IHNpZ25pbmcgKEp1c3RpbiBSaWNoZXIpDQpkcmFm dDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhdmFnZS1odHRwLXNpZ25hdHVy ZXMNCi0tPiBkaXNwYXRjaGVkIHRvIEhUVFBCSVMgV0cNCg0KKDUpIENvbW11bmljYXRpb24gTmV0 d29yayBQZXJzcGVjdGl2ZSBvbiBNYWx3YXJlIExpZmVjeWNsZSAoSm9hY2hpbSBGYWJpbmkpDQpk cmFmdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmFiaW5pLXNtYXJ0 LW1hbHdhcmUtbGlmZWN5Y2xlLw0KLS0+IGNoZWNrIHRoZSBJQUIgcHJvamVjdCAodGFsayB0byBU ZWQpDQoNCig2KSBTZWN1cmluZyBwcm90b2NvbHMgYmV0d2VlbiBwcm94aWVzIGFuZCBiYWNrZW5k IChIVFRQPykgc2VydmVycyAoQnJpYW4gQ2FtcGJlbGwpDQpkcmFmdDogTG9va2luZyBmb3Igc3Vw cG9ydC9jb250cmlidXRvcnMsIG5vIGRyYWZ0IHlldA0KLS0+IG5lZWRzIGRyYWZ0DQoNCkRldGFp bGVkIG1pbnV0ZXMgd2lsbCBiZSBjb21pbmcgaW4gdGhlIG5leHQgY291cGxlIG9mIHdlZWtzLg0K DQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRl IHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIu IFRoYW5rIHlvdS4NCg== --_000_DM6PR11MB3883B6A92EE8946978C6D7E69B0D0DM6PR11MB3883namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzcwMzBBMDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdXBwb3J0IHRoaXMgZWZmb3J0ITxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgbGFjayBvZiBzdWNoIGEgaGVhZGVyIGhhcyBiZWVuIGEgcGFpbiBwb2lu dCBmb3IgbWlncmF0aW5nIGFwcGxpY2F0aW9ucyB3aXRoIGNsaWVudC1jZXJ0IGRyaXZlbiBhdXRo IG1lY2hhbmlzbXMgaW50byB0aGUgY2xvdWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLTxi cj4NCk1pa2UgT3Vuc3dvcnRoPGJyPg0KU29mdHdhcmUgU2VjdXJpdHkgQXJjaGl0ZWN0LCBFbnRy dXN0IERhdGFjYXJkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFNlY2Rpc3BhdGNoICZsdDtzZWNkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5CcmlhbiBDYW1wYmVsbDxi cj4NCjxiPlNlbnQ6PC9iPiBKYW51YXJ5IDE3LCAyMDIwIDI6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+ IEZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5j b21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzZWNkaXNwYXRjaEBpZXRmLm9y Zzsgc2FhZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdUmU6IFtTZWNk aXNwYXRjaF0gU0VDRElTUEFUQ0ggV0cgU3VtbWFyeSBmcm9tIElFVEYgMTA2PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPldBUk5JTkc6PC9zcGFuPjwvc3Ryb25nPiBU aGlzIGVtYWlsIG9yaWdpbmF0ZWQgb3V0c2lkZSBvZiBFbnRydXN0IERhdGFjYXJkLjxicj4NCjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpyZWQiPkRPIE5PVCBDTElDSzwvc3Bhbj48L3N0cm9uZz4gbGlua3Mgb3IgYXR0 YWNobWVudHMgdW5sZXNzIHlvdSB0cnVzdCB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50 IGlzIHNhZmUuPG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEw MCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFwb2xvZ2llcyBmb2xrcywgSSdtIHJlc3BvbnNpYmxlIGZvciB0aGUgcnVzaGVkIGFu ZCBhd2t3YXJkIHByZXNlbnRhdGlvbiBhYm91dCByZXZlcnNlIHByb3hpZXMgYW5kIFRMUyBjbGll bnQgY2VydGlmaWNhdGVzIGF0IHRoZSB2ZXJ5IGVuZCBvZiB0aGUgU0VDRElTUEFUQ0ggc2Vzc2lv biBpbiBTaW5nYXBvcmUsIHdoaWNoIGlzIG1lbnRpb25lZCBiZWxvdyB3aXRoICZxdW90O25vIGRy YWZ0IHlldC0tJmd0OyBuZWVkcyBkcmFmdCZxdW90Oy4NCiBJdCB0b29rIG1lIGEgbGl0dGxlIHdo aWxlIHRvIGdldCB0aHJvdWdoIHRoZSB3b3JrIGJ1dCBJJ20gaGFwcHkgdG8gc2hhcmUgdGhhdCB0 aGVyZSBpcyBub3cgYW4gYWN0dWFsIGRyYWZ0IGF2YWlsYWJsZS4gSGVyZSBpdCBpcyBpbiB0aGUg ZmFuY3kgbmV3IEhUTUwgZm9ybWF0Og0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQv ZHJhZnQtYmRjLXNvbWV0aGluZy1zb21ldGhpbmctY2VydGlmaWNhdGUtMDEuaHRtbCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYmRjLXNvbWV0aGluZy1z b21ldGhpbmctY2VydGlmaWNhdGUtMDEuaHRtbDwvYT4gYXMgd2VsbCBhcyB0aGUgZ29vZCBvbCBz dGF0dXMgcGFnZToNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJkYy1zb21ldGhpbmctc29tZXRoaW5nLWNlcnRpZmljYXRlLyIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmRjLXNvbWV0aGluZy1z b21ldGhpbmctY2VydGlmaWNhdGUvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiAxOSwgMjAxOSBhdCA5 OjM0IFBNIEZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmk9PGEgaHJl Zj0ibWFpbHRvOjQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhlIFNFQ0RJU1BBVENIIFdHIG1ldCBvbiBUdWVzZGF5 IE5vdmVtYmVyIDE5LiZuYnNwOyBUaGUgYWdlbmRhIGl0ZW1zIHdlcmUgZGlzcGF0Y2hlZCBhcyBm b2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPigxKSBQcm9ibGVtIHN0YXRlbWVudCBmb3Ig cG9zdC1xdWFudHVtIG11bHRpLWFsZ29yaXRobSBQS0kgKE1heCBQYWxhKQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+ZHJhZnRz OiZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt cHEtcGtpeC1wcm9ibGVtLXN0YXRlbWVudC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBxLXBraXgtcHJvYmxlbS1zdGF0ZW1lbnQvPC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1vdW5zd29ydGgtcHEtY29tcG9zaXRlLXNpZ3MvIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1vdW5zd29ydGgtcHEtY29t cG9zaXRlLXNpZ3MvPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+LS0mZ3Q7 IGRpc3BhdGNoIHRvIExBTVBTIFdHIChjb25maXJtIG9uIG1haWxpbmcgbGlzdCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj4oMikgT0NTUHYyIC0gSW1wcm92aW5nIE9DU1AgUmVzcG9uc2VzIChNYXgg UGFsYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj5MQU1QUyAmYW1wOyBQS0lYIGRpc2N1c3Npb25zOg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+RHJh ZnQ6Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFs YS1vY3NwdjItMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtcGFsYS1vY3NwdjItMDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+LS0mZ3Q7IGNyZWF0ZSBhIEJvRiBmb3Ig c21hbGwgZm9jdXNlZCBXRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPigzKSBQcml2YWN5IFBhc3MgUHJv dG9jb2wgKE5pY2sgU3VsbGl2YW4pPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5kcmFm dHM6DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wcml2 YWN5LXBhc3MvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtcHJpdmFjeS1wYXNzLzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPi0tJmd0OyB3b3JrIG9uIGNoYXJ0ZXIgdGV4dCB0aGVuIEJvRiBmb3Igc21hbGwgZm9jdXNl ZCBXRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPig0KSBIVFRQIFJlcXVlc3Qgc2lnbmluZyAoSnVz dGluIFJpY2hlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIj5kcmFmdDoNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1jYXZhZ2UtaHR0cC1zaWduYXR1cmVzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2F2YWdlLWh0dHAtc2lnbmF0dXJlczwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPi0tJmd0OyBkaXNwYXRjaGVkIHRvIEhU VFBCSVMgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4oNSkgQ29tbXVuaWNhdGlvbiBOZXR3b3Jr IFBlcnNwZWN0aXZlIG9uIE1hbHdhcmUgTGlmZWN5Y2xlIChKb2FjaGltIEZhYmluaSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5k cmFmdDoNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZh YmluaS1zbWFydC1tYWx3YXJlLWxpZmVjeWNsZS8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhYmluaS1zbWFydC1tYWx3YXJlLWxpZmVj eWNsZS88L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4tLSZndDsgY2hlY2sg dGhlIElBQiBwcm9qZWN0ICh0YWxrIHRvIFRlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4oNikg U2VjdXJpbmcgcHJvdG9jb2xzIGJldHdlZW4gcHJveGllcyBhbmQgYmFja2VuZCAoSFRUUD8pIHNl cnZlcnMgKEJyaWFuIENhbXBiZWxsKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPmRyYWZ0OiBMb29raW5nIGZvciBzdXBwb3J0 L2NvbnRyaWJ1dG9ycywgbm8gZHJhZnQgeWV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+LS0mZ3Q7IG5lZWRzIGRyYWZ0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+RGV0YWlsZWQgbWludXRlcyB3aWxsIGJlIGNvbWluZyBpbiB0 aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhhbmtzLDxi cj4NCkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY20iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl ci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_DM6PR11MB3883B6A92EE8946978C6D7E69B0D0DM6PR11MB3883namp_-- From nobody Tue Jan 21 14:21:13 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C19712001A for ; Tue, 21 Jan 2020 14:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 wPgsi13TKdQs for ; Tue, 21 Jan 2020 14:21:05 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AF012007A for ; Tue, 21 Jan 2020 14:21:05 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id r19so4555456ljg.3 for ; Tue, 21 Jan 2020 14:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H401HRV0g1iZF3sKUemUgVrX03r9UTHCgvu4d5cxG/8=; b=e7Dts01w3lRVBKSwTAA2izFio8488XU3gBMTuX03BHWVSBZ7DPEc83vxNnVGsd8Xyl XVf5bs1wPdsbeYDXJlUysWBN3GtniO9gs9VQtsMDXUPS1rPb4nYi3FcZHfdcgRNwEDc8 Xkuy4S8t46apRsQ4uyENMw0E2+vT91C8OuUKA0DknNBiXxR3qLp7jqwJYY1FDN6Uxzur ep19iBzZSqsid8i7abNTdfGSobSjtkkT3PbC5garqxCf9qsj16Z4PJkwZwPksVz1r6vx RQOtRAtxMLJRTv8UQtoWtUcS2HnXQp3LXEtX4IQMloRlfZbHgrPxRptJr0DN8Tuatkzz JqAg== 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=H401HRV0g1iZF3sKUemUgVrX03r9UTHCgvu4d5cxG/8=; b=PjD/Y9bPQvVlhnoViNYE+CumtpJemhofdjQ3zi2XYeEEkk0uqg2RPMmavK6iigIpO0 97bYngBBkYJRE9+aahJoYXE7tNvcGtv1MZkBGK/TpTfp4bEN42s6JOggdBlTzJUbvDEH Bn4QMSXH4E8234aYQIJf1Np5hf9V6k0w/M8NBQhozQsCYXtVqzmpwSX2K24fyWYv3MOs 7WksPpSgCK3EPx5BH1Z0/3B3QhJRkOK9j/zJxteUwp8a0qo0v4dhItVDmoPBLTc0VMdh 5/2KiZInU29zjRBXvmR6BgXcBH72tGoEcQ7/Tv+3/ddflcb2XucGi7yvoT7KhamKSEYO iHgQ== X-Gm-Message-State: APjAAAUCRg/jsfpZpMzJM9c4nLtQbFC1QWjnSRKmgY01/gI25ksJqJZc a7YtyJ5uA5NR12GPHIJ9d4n6Bhj9UIJGvRjaOAKg7ivYooEmojrNTSHSsUcL8Pnqsv+s4pCByeP ZkAF3gnvC8qh+cOmCpf/mwg== X-Google-Smtp-Source: APXvYqzhaXyULI6m2LEVbr7iCIuDwBGWOotzXCoJj39iqFpL3jkYM39WANssb/si/XezlZ93lbpEFfw0h8VklI8oEQY= X-Received: by 2002:a2e:9cd2:: with SMTP id g18mr15314042ljj.272.1579645263288; Tue, 21 Jan 2020 14:21:03 -0800 (PST) MIME-Version: 1.0 References: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> <22451.1579452735@localhost> <4920.1579540711@localhost> In-Reply-To: <4920.1579540711@localhost> From: Brian Campbell Date: Tue, 21 Jan 2020 15:20:36 -0700 Message-ID: To: Michael Richardson Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ca3549059cadd296" Archived-At: Subject: Re: [Secdispatch] [saag] SECDISPATCH WG Summary from IETF 106 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 22:21:11 -0000 --000000000000ca3549059cadd296 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2020 at 10:18 AM Michael Richardson wrote: > > bc> Via email exchange it's not entirely clear whether that's a > compliment or a > bc> criticism or just an observation. > > compliment. > I'll take it. Thank you :) bc> For better or worse, I tried to choose a name that's meaningful and > bc> shortish. And one that doesn't look like it came from the default > bc> documentation of some popular web server. > > My point is to > a) point to de-facto names which are currently being used to demonstrat= e > the need for a standard. > b) indicate if the contents are the same or different. > Got it and point taken. bc> In writing up this initial draft, I waffled about whether or not to > include > bc> intermediate signers and/or the whole chain. Although I landed on > only > bc> passing the leaf certificate, this is certainly something that's > up for > bc> discussion should this document find a home where it can be worke= d > on and > bc> progressed. > > good, we agree. > Isn't httpbis the obvious WG here? > It seems a likely candidate, yeah. The issue that the draft aspires to address certainly isn't new. But it reared its head again on the OAUTH WG list not too long ago before the last meeting. When the prospect of trying to standardize something came up, one of the SEC ADs encouraged me to bring a presentation and/or draft to SECDISPATCH. That was right before the I-D cutoff pre Singapore so I just started with a presentation there, which was rushed due to time constraints and basically the suggestion coming out of the meeting was to write a draft. I just recently got this little draft written, which brings us to where we are now. And I guess that basically amounts to looking for some direction from SECDISPATCH and/or gauging interest or appetite for the work. It could be that we should have two headers. > One for the EE, and one (or many?) for the chain. > That's certainly a possibility. And I think not inconsistent with what some existing proxies will do now. bc> True, the reverse proxy can not control what is sent to it. But > it's meant > bc> to be normative language towards other forward proxies and other > bc> intermediaries to say that they can't/shouldn't be adding this > thing. Which > bc> seems legit (and something I'm told is supposed to be covered for > registry > bc> requests on header fields). Perhaps that text can be moved or > adjusted in a > bc> way that makes the distinction more clear. > > Sure. I'm saying no normative language about another entity. > The normative language should say that reverse proxies MUST remove the > header > when coming in. > Gotcha > > >> You already handle this: > >> 2) Any occurrence of the Client-Cert header in the original incomi= ng > >> request MUST be removed or overwritten before forwarding the > request. > >> > >> and leave it like that, maybe emphasis this. > >> Maybe reverse proxies SHOULD reject requests that have a > Client-Cert header > >> in them, period? > >> > > bc> That's certainly an option. I suppose there are tradeoffs between > rejecting > bc> vs. cleaning such requests. Maybe a MAY would be appropriate for > something > bc> like that so as to give the proxy the option. Again, that's > something that > bc> could be fleshed out in discussions if this thing finds a home. > > It seems like a request that arrives with Client-Cert in it is at best > misconfiguration, and at worse an attack. It can't be legitimate. > I think that being tolerant here does not benefit anyone. > When phrased like that, the case for intolerance does sound pretty strong. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ca3549059cadd296 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 20, 2020 at 10:18 AM Mich= ael Richardson <mcr+ietf@sand= elman.ca> wrote:

=C2=A0 =C2=A0 bc> Via email exchange it's not entirely clear whether= that's a compliment or a
=C2=A0 =C2=A0 bc> criticism or just an observation.

compliment.

I'll take it. Thank you= :)


=C2=A0 =C2=A0 bc> For better or worse, I tried to choose a name that'= ;s meaningful and
=C2=A0 =C2=A0 bc> shortish. And one that doesn't look like it came f= rom the default
=C2=A0 =C2=A0 bc> documentation of some popular web server.

My point is to
=C2=A0 a) point to de-facto names which are currently being used to demonst= rate
=C2=A0 =C2=A0 =C2=A0the need for a standard.
=C2=A0 b) indicate if the contents are the same or different.

Got it and point taken.
=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> =C2=A0 =C2=A0 bc> In writing up this initial draft, I waffled about whet= her or not to include
=C2=A0 =C2=A0 bc> intermediate signers and/or the whole chain. Although = I landed on only
=C2=A0 =C2=A0 bc> passing the leaf certificate, this is certainly someth= ing that's up for
=C2=A0 =C2=A0 bc> discussion should this document find a home where it c= an be worked on and
=C2=A0 =C2=A0 bc> progressed.

good, we agree.
Isn't httpbis the obvious WG here?

= It seems a likely candidate, yeah.

The issue = that the draft aspires to address certainly isn't new. But it reared it= s head again on the OAUTH WG list not too long ago before the last meeting.= When the prospect of trying to standardize something came up, one of the S= EC ADs encouraged me to bring a presentation and/or draft to SECDISPATCH. T= hat was right before the I-D cutoff pre Singapore so I just started with a = presentation there, which was rushed due to time constraints and basically = the suggestion coming out of the meeting was to write a draft. I just recen= tly got this little draft written, which brings us to where we are now. And= I guess that basically amounts to looking for some direction from SECDISPA= TCH and/or gauging interest or appetite for the work.
=C2=A0=

It could be that we should have two headers.
One for the EE, and one (or many?) for the chain.

=
=C2=A0That's certainly a possibility. And I think not incons= istent with what some existing proxies will do now.
=C2=A0

=C2=A0 =C2=A0 bc> True, the reverse proxy can not control what is sent t= o it. But it's meant
=C2=A0 =C2=A0 bc> to be normative language towards other forward proxies= and other
=C2=A0 =C2=A0 bc> intermediaries to say that they can't/shouldn'= t be adding this thing. Which
=C2=A0 =C2=A0 bc> seems legit (and something I'm told is supposed to= be covered for registry
=C2=A0 =C2=A0 bc> requests on header fields). Perhaps that text can be m= oved or adjusted in a
=C2=A0 =C2=A0 bc> way that makes the distinction more clear.

Sure. I'm saying no normative language about another entity.
The normative language should say that reverse proxies MUST remove the head= er
when coming in.

Gotcha
=C2=A0=

=C2=A0 =C2=A0 >> You already handle this:
=C2=A0 =C2=A0 >> 2) Any occurrence of the Client-Cert header in the o= riginal incoming
=C2=A0 =C2=A0 >> request MUST be removed or overwritten before forwar= ding the request.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> and leave it like that, maybe emphasis this.
=C2=A0 =C2=A0 >> Maybe reverse proxies SHOULD reject requests that ha= ve a Client-Cert header
=C2=A0 =C2=A0 >> in them, period?
=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 bc> That's certainly an option. I suppose there are tr= adeoffs between rejecting
=C2=A0 =C2=A0 bc> vs. cleaning such requests. Maybe a MAY would be appro= priate for something
=C2=A0 =C2=A0 bc> like that so as to give the proxy the option. Again, t= hat's something that
=C2=A0 =C2=A0 bc> could be fleshed out in discussions if this thing find= s a home.

It seems like a request that arrives with Client-Cert in it is at best
misconfiguration, and at worse an attack.=C2=A0 It can't be legitimate.=
I think that being tolerant here does not benefit anyone.
<= div>
When phrased like that, the case for intolerance does so= und pretty strong.
=C2=A0

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000ca3549059cadd296-- From nobody Wed Jan 22 13:03:40 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D6B120885 for ; Wed, 22 Jan 2020 13:03:39 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.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 DAKCsJt9e_Ns for ; Wed, 22 Jan 2020 13:03:37 -0800 (PST) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 4DD5E12087B for ; Wed, 22 Jan 2020 13:03:37 -0800 (PST) Received: from pps.filterd (m0170391.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00ML0A3u021836 for ; Wed, 22 Jan 2020 16:03:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=OUJRlagidexg/orD8XqCrp9TL2EVk3Oznr1Hbg+TwUE=; b=M6221PMMHjgEMln+lEY07VXPJUnvd/mu9kCTF0eot4x8kcb7SPQijfHHkzDDjNXsUPj3 Fep7BrvRu0RM/7+yoqtdnHBYbz+GmtK+f1Eas4zFJeUsdNlhadeTIg0hfSBYJ2pvWK9x cUPxThbnErrYueiwcX1hLj8jjbrUCLdeQyNpmYP5OaLMgFml0TlqdCnLyNVsymiyYOMq m1SO9PlkvrIvD99LdCQ2JN1HvRzdB1S6zACs4a3DsshysYtJYv/d5pyXAa4QcPU2tFwh CNW6TDDkNZpo4U4bOITG7ZEF1X1gaZCk01hN/tOBfOwHQqn62Vp7gIWOnX7Nj0GseefK XQ== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2xpv9h0e6x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 22 Jan 2020 16:03:36 -0500 Received: from pps.filterd (m0134746.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00MKwMnX162020 for ; Wed, 22 Jan 2020 16:03:36 -0500 Received: from ausxippc110.us.dell.com (AUSXIPPC110.us.dell.com [143.166.85.200]) by mx0a-00154901.pphosted.com with ESMTP id 2xpt1k40sy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 22 Jan 2020 16:03:36 -0500 X-LoopCount0: from 10.166.132.128 X-PREM-Routing: D-Outbound X-IronPort-AV: E=Sophos;i="5.60,349,1549951200"; d="scan'208";a="907418284" From: To: CC: Thread-Topic: New Version Notification for draft-faibish-iot-ddos-usecases-01.txt Thread-Index: AQHVu2eQmpLQttK5yE+1FHWFMMTBsqf3UwYw Date: Wed, 22 Jan 2020 21:03:32 +0000 Message-ID: <3d6e25481f044ea182fbfe06bf8ccd0c@x13pwdurdag1001.AMER.DELL.COM> References: <157730815035.29082.3329281957041349799.idtracker@ietfa.amsl.com> In-Reply-To: <157730815035.29082.3329281957041349799.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=faibish_sorin@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-01-22T21:03:30.8708167Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.146.130.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-22_08:2020-01-22, 2020-01-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 spamscore=0 mlxscore=0 priorityscore=1501 clxscore=1015 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001220179 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 clxscore=1015 phishscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001220179 Archived-At: Subject: [Secdispatch] FW: New Version Notification for draft-faibish-iot-ddos-usecases-01.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 21:03:39 -0000 RGVhciBzZWNkaXNwYXRjaCBjaGFpcnMsDQoNCkZvciB0aGUgbGFzdCB5ZWFyIEkgd29ya2VkIG9u IHRoaXMgZHJhZnQgZGVmaW5pbmcgdXNlY2FzZXMgb2YgSW9UIGRldmljZXMgZXhwbG9pdGVkIGZv ciBERG9TIGF0dGFja3MgaW4gdGhlIFRFRVAgV0cuIFRoZSBwdXJwb3NlIG9mIHRoZSBkcmFmdCBp cyB0byBwcmVzZW50IHRoZSBwcm9ibGVtIGFuZCBpZiBhcHByb3ZlZCB0byB3cml0ZSBhIHNlY29u ZCBkcmFmdCB3aXRoIHByZXZlbnRpb24gcHJvdG9jb2wuIExhc3QgbWVldGluZyBURUVQIGRlY2lk ZWQgbm90IHRvIHB1cnN1ZSB0aGlzIGRyYWZ0IGFzIHBhcnQgb2YgdGhlIFRFRVAgV0cgYXMgb3V0 IG9mIHNjb3BlLiBBcyBhIHJlc3VsdCBJIHdhbnQgdG8gbWFrZSB0aGUgY2FzZSBzbyB0aGlzIHBy b3RvY29sIHByb3Bvc2FsIHRvIGJlY29tZSBhIHNlY2Rpc3BhdGNoIGRyYWZ0LiBEdXJpbmcgdGhl IHdvcmsgb24gdGhpcyBkcmFmdCBJIGFsc28gc3RhcnRlZCB0byBidWlsZCBhIHRvb2wgdGhhdCB3 aWxsIGFsbG93IGNoZWNraW5nIElvVCBkZXZpY2VzIHZ1bG5lcmFiaWxpdHkgdG8gYmUgdXNlZCB0 byBjaGVjayBwb3RlbnRpYWwgb3Bwb3J0dW5pdHkgdG8gdXNlIHRoZSBzcGVjaWZpYyBJb1QgZGV2 aWNlcyBhcyBtZWFucyBmb3IgRERvUyBhdHRhY2tzLiBJIHRlc3RlZCB0aGUgZmlyc3QgdmVyc2lv biBhdCB0aGUgSGFja2F0aG9uIGF0IElFVEYgMTA1IGluIE1vbnRyZWFsIHdpdGhpbiB0aGUgVEVF UCBXRyBidXQgdGhlcmUgd2VyZSBubyBJb1QgZGV2aWNlcyBwcm90b3R5cGVzIGF0IGhhY2thdGhv biBzbywgSSB3YXMgb25seSBhYmxlIHRvIHNlbGYgdGVzdC4gDQoNCkkgd2FudCB0byBhc2sgYSAx NSBtaW51dGVzIHRpbWUgc2xvdCBpbiB0aGUgc2VjZGlzcGF0Y2ggbWVldGluZyBkdXJpbmcgdGhl IElFVEYgMTA3IGluIFZhbmNvdXZlciBhcyB3ZWxsIGFzIHByZXNlbnRpbmcgdGhlIHB5dGhvbiB0 b29sIHRvIGJlIHVzZWQgYnkgb3RoZXIgaW50ZXJlc3RlZCBwYXJ0aWVzIHRvIHRlc3QgdGhlaXIg b3duIElvVCBkZXZpY2VzLiBJIHdpbGwgYWdhaW4gYXR0ZW5kIHRoZSBIYWNrYXRob24gaW4gVmFu Y291dmVyIGFuZCBjaGVjayB0aGUgSW9UIGRldmljZXMgdGhhdCB3aWxsIGJlIGJyb3VnaHQgYnkg YW55IFdHLiBJIHdpbGwgc3RpbGwgYXR0ZW5kIHRoZSBURUVQIG1lZXRpbmdzIGFzIHdlbGwuIA0K DQpUaGUgdG9vbCBpcyBzY2FubmluZyBhbnkgbmV0d29yayBwcm90b2NvbCBhbmQgb3BlbiBwb3J0 cyB0byBjaGVjayB2dWxuZXJhYmlsaXR5IHRvIGJlIHVzZWQgYnkgYmFkIGFjdG9ycyB0byBzdGFy dCByZWZsZWN0aW9uIEREb1MgYXR0YWNrcyBmcm9tIHRoZSBkZXZpY2UuIFRoZSBjb21wbGlhbmNl IHRvb2wgcnVucyBQeXRob24gY29kZSwgdG8gc2NhbiBhbiBJb1QgZGV2aWNlIChsb2NhbCBvciBl eHRlcm5hbCkgZm9yIG9wZW4gcG9ydHMsIGJhc2VkIG9uIHRoZSBtb3N0IGNvbW1vbiA0MiBwb3J0 cyAoVENQIGFuZCBVRFApIHVzZWQgYnkgSW9Ucy4gVGhlc2UgcG9ydCBzY2FuIHJlc3VsdHMgYXJl IHRoZW4gY29tcGFyZWQgd2l0aCB0aGUgTVVEIGZpbGUgdGhhdCBpcyBwcm92aWRlZCBieSB0aGUg dXNlciBmb3IgdGhlIHNwZWNpZmljIElvVCwgc2luY2UgZXZlcnkgTVVEIGZpbGUgaXMgdGFpbG9y ZWQgdG8gdGhhdCBzcGVjaWZpYyBtYW51ZmFjdHVyZXLigJlzIElvVCBtb2RlbC4gVGhlIHNvdXJj ZS1wb3J0cyAoVENQIGFuZCBVRFApIG1lbnRpb25lZCBpbiB0aGUgTVVEIGFyZSBleHRyYWN0ZWQg YnkgdGhlIFB5dGhvbiBwcm9ncmFtIGFuZCB0aGVuIGNvbXBhcmVkIGFnYWluc3QgdGhlIDQyIHBv cnRzIHNjYW5uZWQgZWFybGllci4gVGhlcmUgaXMgYWxzbyBhIE1VRCB2aXN1YWxpemVyLCB0aGF0 IHRha2VzIGluIGEgTVVEIGZpbGUgYW5kIHNob3dzIHRoZSBpbmNvbWluZyBhbmQgb3V0Z29pbmcg dHJhZmZpYyBiYXNlZCBvbiB0aGUgSlNPTiBNVUQgZmlsZS4gWW91IG1heSBhbHNvIG1ha2UgYSBN VUQgZmlsZS4NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBzdXBwb3J0DQoNCi4vU29y aW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiANClNlbnQ6IFdlZG5lc2RheSwgRGVj ZW1iZXIgMjUsIDIwMTkgNDowOSBQTQ0KVG86IGZhaWJpc2gsIHNvcmluDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZhaWJpc2gtaW90LWRkb3MtdXNlY2FzZXMt MDEudHh0DQoNCg0KW0VYVEVSTkFMIEVNQUlMXSANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtZmFpYmlzaC1pb3QtZGRvcy11c2VjYXNlcy0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgU29yaW4gRmFpYmlzaCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1mYWliaXNoLWlvdC1kZG9zLXVzZWNhc2VzDQpSZXZp c2lvbjoJMDENClRpdGxlOgkJVXNlY2FzZXMgZGVmaW5pdGlvbiBmb3IgSW9UIEREb1MgYXR0YWNr cyBwcmV2ZW50aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE5LTEyLTI1DQpHcm91cDoJCUluZGl2aWR1 YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk5DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZhaWJpc2gtaW90LWRkb3MtdXNlY2FzZXMtMDEu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmFpYmlzaC1pb3QtZGRvcy11c2VjYXNlcy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmFpYmlzaC1pb3QtZGRvcy11c2VjYXNlcy0wMQ0KSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt ZmFpYmlzaC1pb3QtZGRvcy11c2VjYXNlcw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mYWliaXNoLWlvdC1kZG9zLXVzZWNhc2VzLTAxDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgc2V2ZXJhbCB1c2VjYXNlcyBy ZWxhdGVkIHRvIHRoZSBkaWZmZXJlbnQNCiAgIHdheXMgSW9UIGRldmljZXMgYXJlIGV4cGxvaXRl ZCBieSBtYWxpY2lvdXMgYWR2ZXJzYXJpZXMgdG8NCiAgIGluc3RhbnRpYXRlIERpc3RyaWJ1dGVk IERlbmlhbCBvZiBTZXJ2aWNlcyAoRERvUykgYXR0YWNrcy4gVGhlDQogICBhdHRhY2tzIGFyZSBn ZW5lcnRlZCBmcm9tIElvVCBkZXZpY2VzIHRoYXQgaGF2ZSBubyBwcm9wZXIgcHJvdGVjdGlvbg0K ICAgYWdhaW5zdCBnZW5lcmF0aW5nIHVuc29saWNpdGVkIGNvbW11bmljYXRpb24gbWVzc2FnZXMg dGFyZ2V0aW5nIGENCiAgIGNlcnRhaW4gbmV0d29yayBhbmQgY3JlYXRpbmcgbGFyZ2UgYW1vdW50 cyBvZiBuZXR3b3JrIHRyYWZmaWMuIFRoZQ0KICAgYXR0YWNrZXJzIHRha2UgYWR2YW50YWdlIG9m IGJyZWFjaGVzIGluIHRoZSBjb25maWd1cmF0aW9uIGRhdGEgaW4NCiAgIHVucHJvdGVjdGVkIElv VCBkZXZpY2VzIGV4cGxvaXRlZCBmb3IgRERvUyBhdHRhY2tzLiBUaGUgYXR0YWNrZXJzDQogICB0 YWtlIGFkdmFudGFnZSBvZiB0aGUgSW9UIGRldmljZXMgdGhhdCBjYW4gc2VuZCBuZXR3b3JrIHBh Y2tldHMNCiAgIHRoYXQgd2VyZSBnZW5lcmF0ZWQgYnkgbWFsaWNpb3VzIGNvZGUgdGhhdCBpbnRl cmFjdHMgd2l0aCBhbiBPUw0KICAgaW1wbGVtZW50YXRpb24gdGhhdCBydW5zIG9uIHRoZSBJb1Qg ZGV2aWNlcy4gVGhlIHBydXBvc2Ugb2YgdGhpcw0KICAgZHJhZnQgaXMgdG8gcHJlc2VudCBwb3Nz aWJsZSBJb1QgRERvUyB1c2VjYXNlcyB0aGF0IG5lZWQgdG8gYmUNCiAgIHByZXZlbnRlZCBieSBU RUUuIFRoZSBtYWpvciBlbmFibGVyIG9mIHN1Y2ggYXR0YWNrcyBpcyByZWxhdGVkIHRvDQogICBJ b1QgZGV2aWNlcyB0aGF0IGhhdmUgbm8gT1Mgb3IgdW5wcm90ZWN0ZWQgRUUgT1MgYW5kIHJ1bg0K ICAgY29kZSB0aGF0IGlzIGRvd25sb2FkZWQgdG8gdGhlbSBmcm9tIHRoZSBUQSBhbmQgbW9kaWZp ZWQgYnkNCiAgIG1hbi1pbi10aGUtbWlkZGxlIHRoYXQgaW5zZXJ0cyBtYWxpY2lvdXMgY29kZSBp biB0aGUgT1MuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jan 22 13:42:50 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F3F120091 for ; Wed, 22 Jan 2020 13:42:47 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.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 UNMf8wfyY5K9 for ; Wed, 22 Jan 2020 13:42:43 -0800 (PST) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 D291E12001B for ; Wed, 22 Jan 2020 13:42:43 -0800 (PST) Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00MLU8cI024226 for ; Wed, 22 Jan 2020 16:42:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=633E37+DT9bZk95z2L84RnQvjy2rYy6K8L5zRJ5mSlE=; b=TBcKGWmhpt4vti7miY8xUf21Y4/rsBQ+ygOC/rCait7wpjNRw/F9xniBef/5sonQWImY 4wyAfdmZ7gQAbV9lqYiFn/vxwbd8/WJ43txDNqAu1GgmevekFrYB3TB4MviC/jAi6+lV 59twbk28E7wuQNHGnjX54FVCbJJscDoc47DNvLEs+wZfQbmE81IO8ojbC8FTPCIAZLaX pYoBrjd823ePoEV1Tmfw4m8vru2u/fBwb972kU9DW1f+meoByT9I2hbnZOKo9wj54b01 RzW8SzEt/UtnOkseS5S0mmBNJRno4duYFBe7OFJZP4UpxoBzEVSPrwcspzwIdmX9Stlq XA== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2xkwy7apjj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 22 Jan 2020 16:42:43 -0500 Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00MLSPQw181656 for ; Wed, 22 Jan 2020 16:42:42 -0500 Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by mx0b-00154901.pphosted.com with ESMTP id 2xps555aw8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 22 Jan 2020 16:42:42 -0500 X-LoopCount0: from 10.166.132.195 X-PREM-Routing: D-Outbound X-IronPort-AV: E=Sophos;i="5.60,346,1549951200"; d="scan'208";a="1350186108" From: To: CC: Thread-Topic: New Draft Notification for draft-faibish-iot-ddos-usecases-01.txt Thread-Index: AdXRbNx/hkX8iruETDWX4ppimBDk7A== Date: Wed, 22 Jan 2020 21:42:39 +0000 Message-ID: <0714fc59468c496c9f49ab30a222eb80@x13pwdurdag1001.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=faibish_sorin@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-01-22T21:03:30.8708167Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.146.130.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-22_08:2020-01-22, 2020-01-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 spamscore=0 adultscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 clxscore=1015 impostorscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001220182 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999 phishscore=0 clxscore=1015 priorityscore=1501 mlxscore=0 suspectscore=0 bulkscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001220182 Archived-At: Subject: [Secdispatch] New Draft Notification for draft-faibish-iot-ddos-usecases-01.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 21:42:48 -0000 RGVhciBzZWNkaXNwYXRjaCBjaGFpcnMsDQoNCkZvciB0aGUgbGFzdCB5ZWFyIEkgd29ya2VkIG9u IHRoaXMgZHJhZnQgZGVmaW5pbmcgdXNlY2FzZXMgb2YgSW9UIGRldmljZXMgZXhwbG9pdGVkIGZv ciBERG9TIGF0dGFja3MgaW4gdGhlIFRFRVAgV0cuIFRoZSBwdXJwb3NlIG9mIHRoZSBkcmFmdCBp cyB0byBwcmVzZW50IHRoZSBwcm9ibGVtIGFuZCBpZiBhcHByb3ZlZCB0byB3cml0ZSBhIHNlY29u ZCBkcmFmdCB3aXRoIHByZXZlbnRpb24gcHJvdG9jb2wuIExhc3QgbWVldGluZyBURUVQIGRlY2lk ZWQgbm90IHRvIHB1cnN1ZSB0aGlzIGRyYWZ0IGFzIHBhcnQgb2YgdGhlIFRFRVAgV0cgYXMgb3V0 IG9mIHNjb3BlLiBBcyBhIHJlc3VsdCBJIHdhbnQgdG8gbWFrZSB0aGUgY2FzZSBzbyB0aGlzIHBy b3RvY29sIHByb3Bvc2FsIHRvIGJlY29tZSBhIHNlY2Rpc3BhdGNoIGRyYWZ0LiBEdXJpbmcgdGhl IHdvcmsgb24gdGhpcyBkcmFmdCBJIGFsc28gc3RhcnRlZCB0byBidWlsZCBhIHRvb2wgdGhhdCB3 aWxsIGFsbG93IGNoZWNraW5nIElvVCBkZXZpY2VzIHZ1bG5lcmFiaWxpdHkgdG8gYmUgdXNlZCB0 byBjaGVjayBwb3RlbnRpYWwgb3Bwb3J0dW5pdHkgdG8gdXNlIHRoZSBzcGVjaWZpYyBJb1QgZGV2 aWNlcyBhcyBtZWFucyBmb3IgRERvUyBhdHRhY2tzLiBJIHRlc3RlZCB0aGUgZmlyc3QgdmVyc2lv biBhdCB0aGUgSGFja2F0aG9uIGF0IElFVEYgMTA1IGluIE1vbnRyZWFsIHdpdGhpbiB0aGUgVEVF UCBXRyBidXQgdGhlcmUgd2VyZSBubyBJb1QgZGV2aWNlcyBwcm90b3R5cGVzIGF0IGhhY2thdGhv biBzbywgSSB3YXMgb25seSBhYmxlIHRvIHNlbGYgdGVzdC4gDQoNClRoZSBweXRob24gdGVzdCB0 b29sIGlzIHNjYW5uaW5nIGFueSBuZXR3b3JrIHByb3RvY29sIGFuZCBvcGVuIHBvcnRzIHRvIGNo ZWNrIHZ1bG5lcmFiaWxpdHkgdG8gYmUgdXNlZCBieSBiYWQgYWN0b3JzIHRvIHN0YXJ0IHJlZmxl Y3Rpb24gRERvUyBhdHRhY2tzIGZyb20gdGhlIGRldmljZS4gVGhlIGNvbXBsaWFuY2UgdG9vbCBy dW5zIFB5dGhvbiBjb2RlLCB0byBzY2FuIGFuIElvVCBkZXZpY2UgKGxvY2FsIG9yIGV4dGVybmFs KSBmb3Igb3BlbiBwb3J0cywgYmFzZWQgb24gdGhlIG1vc3QgY29tbW9uIDQyIHBvcnRzIChUQ1Ag YW5kIFVEUCkgdXNlZCBieSBJb1RzLiBUaGVzZSBwb3J0IHNjYW4gcmVzdWx0cyBhcmUgdGhlbiBj b21wYXJlZCB3aXRoIHRoZSBNVUQgZmlsZSB0aGF0IGlzIHByb3ZpZGVkIGJ5IHRoZSB1c2VyIGZv ciB0aGUgc3BlY2lmaWMgSW9ULCBzaW5jZSBldmVyeSBNVUQgZmlsZSBpcyB0YWlsb3JlZCB0byB0 aGF0IHNwZWNpZmljIG1hbnVmYWN0dXJlcuKAmXMgSW9UIG1vZGVsLiBUaGUgc291cmNlLXBvcnRz IChUQ1AgYW5kIFVEUCkgbWVudGlvbmVkIGluIHRoZSBNVUQgYXJlIGV4dHJhY3RlZCBieSB0aGUg UHl0aG9uIHByb2dyYW0gYW5kIHRoZW4gY29tcGFyZWQgYWdhaW5zdCB0aGUgNDIgcG9ydHMgc2Nh bm5lZCBlYXJsaWVyLiBUaGVyZSBpcyBhbHNvIGEgTVVEIHZpc3VhbGl6ZXIsIHRoYXQgdGFrZXMg aW4gYSBNVUQgZmlsZSBhbmQgc2hvd3MgdGhlIGluY29taW5nIGFuZCBvdXRnb2luZyB0cmFmZmlj IGJhc2VkIG9uIHRoZSBKU09OIE1VRCBmaWxlLiBZb3UgbWF5IGFsc28gbWFrZSBhIE1VRCBmaWxl Lg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHN1cHBvcnQNCg0KLi9Tb3Jpbg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IA0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAy NSwgMjAxOSA0OjA5IFBNDQpUbzogZmFpYmlzaCwgc29yaW4NClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmFpYmlzaC1pb3QtZGRvcy11c2VjYXNlcy0wMS50eHQN Cg0KDQpbRVhURVJOQUwgRU1BSUxdIA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1m YWliaXNoLWlvdC1kZG9zLXVzZWNhc2VzLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBTb3JpbiBGYWliaXNoIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LWZhaWJpc2gtaW90LWRkb3MtdXNlY2FzZXMNClJldmlzaW9uOgkw MQ0KVGl0bGU6CQlVc2VjYXNlcyBkZWZpbml0aW9uIGZvciBJb1QgRERvUyBhdHRhY2tzIHByZXZl bnRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTktMTItMjUNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtZmFpYmlzaC1pb3QtZGRvcy11c2VjYXNlcy0wMS50eHQNClN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYWli aXNoLWlvdC1kZG9zLXVzZWNhc2VzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1mYWliaXNoLWlvdC1kZG9zLXVzZWNhc2VzLTAxDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1mYWliaXNo LWlvdC1kZG9zLXVzZWNhc2VzDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWZhaWJpc2gtaW90LWRkb3MtdXNlY2FzZXMtMDENCg0KQWJzdHJh Y3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBzZXZlcmFsIHVzZWNhc2VzIHJlbGF0ZWQg dG8gdGhlIGRpZmZlcmVudA0KICAgd2F5cyBJb1QgZGV2aWNlcyBhcmUgZXhwbG9pdGVkIGJ5IG1h bGljaW91cyBhZHZlcnNhcmllcyB0bw0KICAgaW5zdGFudGlhdGUgRGlzdHJpYnV0ZWQgRGVuaWFs IG9mIFNlcnZpY2VzIChERG9TKSBhdHRhY2tzLiBUaGUNCiAgIGF0dGFja3MgYXJlIGdlbmVydGVk IGZyb20gSW9UIGRldmljZXMgdGhhdCBoYXZlIG5vIHByb3BlciBwcm90ZWN0aW9uDQogICBhZ2Fp bnN0IGdlbmVyYXRpbmcgdW5zb2xpY2l0ZWQgY29tbXVuaWNhdGlvbiBtZXNzYWdlcyB0YXJnZXRp bmcgYQ0KICAgY2VydGFpbiBuZXR3b3JrIGFuZCBjcmVhdGluZyBsYXJnZSBhbW91bnRzIG9mIG5l dHdvcmsgdHJhZmZpYy4gVGhlDQogICBhdHRhY2tlcnMgdGFrZSBhZHZhbnRhZ2Ugb2YgYnJlYWNo ZXMgaW4gdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBpbg0KICAgdW5wcm90ZWN0ZWQgSW9UIGRldmlj ZXMgZXhwbG9pdGVkIGZvciBERG9TIGF0dGFja3MuIFRoZSBhdHRhY2tlcnMNCiAgIHRha2UgYWR2 YW50YWdlIG9mIHRoZSBJb1QgZGV2aWNlcyB0aGF0IGNhbiBzZW5kIG5ldHdvcmsgcGFja2V0cw0K ICAgdGhhdCB3ZXJlIGdlbmVyYXRlZCBieSBtYWxpY2lvdXMgY29kZSB0aGF0IGludGVyYWN0cyB3 aXRoIGFuIE9TDQogICBpbXBsZW1lbnRhdGlvbiB0aGF0IHJ1bnMgb24gdGhlIElvVCBkZXZpY2Vz LiBUaGUgcHJ1cG9zZSBvZiB0aGlzDQogICBkcmFmdCBpcyB0byBwcmVzZW50IHBvc3NpYmxlIElv VCBERG9TIHVzZWNhc2VzIHRoYXQgbmVlZCB0byBiZQ0KICAgcHJldmVudGVkIGJ5IFRFRS4gVGhl IG1ham9yIGVuYWJsZXIgb2Ygc3VjaCBhdHRhY2tzIGlzIHJlbGF0ZWQgdG8NCiAgIElvVCBkZXZp Y2VzIHRoYXQgaGF2ZSBubyBPUyBvciB1bnByb3RlY3RlZCBFRSBPUyBhbmQgcnVuDQogICBjb2Rl IHRoYXQgaXMgZG93bmxvYWRlZCB0byB0aGVtIGZyb20gdGhlIFRBIGFuZCBtb2RpZmllZCBieQ0K ICAgbWFuLWluLXRoZS1taWRkbGUgdGhhdCBpbnNlcnRzIG1hbGljaW91cyBjb2RlIGluIHRoZSBP Uy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Jan 22 14:05:20 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35725120091 for ; Wed, 22 Jan 2020 14:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blAyuf5VpsWx for ; Wed, 22 Jan 2020 14:05:16 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4C3120041 for ; Wed, 22 Jan 2020 14:05:15 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C736E3897E; Wed, 22 Jan 2020 17:04:40 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6AA6EC69; Wed, 22 Jan 2020 17:05:13 -0500 (EST) From: Michael Richardson To: Faibish.Sorin@dell.com cc: secdispatch@ietf.org, Kathleen.Moriarty@dell.com In-Reply-To: <3d6e25481f044ea182fbfe06bf8ccd0c@x13pwdurdag1001.AMER.DELL.COM> References: <157730815035.29082.3329281957041349799.idtracker@ietfa.amsl.com> <3d6e25481f044ea182fbfe06bf8ccd0c@x13pwdurdag1001.AMER.DELL.COM> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] FW: New Version Notification for draft-faibish-iot-ddos-usecases-01.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 22:05:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I took a quick look through your document. wrote: > with prevention protocol. Last meeting TEEP decided not to pursue this > draft as part of the TEEP WG as out of scope. As a result I want to It certainly does seem out of scope for TEEP. SUIT maybe, but even there that work has been done. Perhaps it belongs with the MUD work as motivation= al evidence, but I don't see anything particularly new. Or with the IoT Lifecycle Security work that I've suggested, but it would still be motivational document, maybe some kind of BCP once other specs rea= ch RFC and we have some experience with them. > I want to ask a 15 minutes time slot in the secdispatch meeting during > the IETF 107 in Vancouver as well as presenting the python tool to be > used by other interested parties to test their own IoT devices. I will I'm sure that the tool is very interesting, but I don't see why secdispatch should care.=20=20 I suggest that you might want to do a Happy Hackdemo presentation, or a scr= eencast. > The tool is scanning any network protocol and open ports to check > vulnerability to be used by bad actors to start reflection DDoS attac= ks > from the device. The compliance tool runs Python code, to scan an IoT > device (local or external) for open ports, based on the most common 42 > ports (TCP and UDP) used by IoTs. These port scan results are then So, we've had tools like this for decades with mixed history of open source and GPL and formerly this license and then another, and sometimes huge VC behind them, and sometimes not. The IETF doesn't standardized them, fund them, promote them, etc. So unless the tool requires IANA actions, I don't see why it belongs here. That's not to see it I'm un-interested, but it has no IETF-interest. This feels like something that you write write a Usenet paper, NDSS, PythonConf, ... paper for. Or maybe just a really cool Screencast that you upload to youtube. > compared with the MUD file that is provided by the user for the > specific IoT, since every MUD file is tailored to that specific > manufacturer=E2=80=99s IoT model. The source-ports (TCP and UDP) ment= ioned in > the MUD are extracted by the Python program and then compared against > the 42 ports scanned earlier. There is also a MUD visualizer, that > takes in a MUD file and shows the incoming and outgoing traffic based > on the JSON MUD file. You may also make a MUD file. > Thank you very much for your support > Name: draft-faibish-iot-ddos-usecases Revision: 01 Title: Usecases > definition for IoT DDoS attacks prevention Document date: 2019-12-25 > Group: Individual Submission Pages: 9 URL: > https://www.ietf.org/internet-drafts/draft-faibish-iot-ddos-usecases-= 01.txt > Status: > https://datatracker.ietf.org/doc/draft-faibish-iot-ddos-usecases/ > Htmlized: > https://tools.ietf.org/html/draft-faibish-iot-ddos-usecases-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-faibish-iot-ddos-usecases > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-faibish-iot-ddos-usecases-01 > Abstract: This document specifies several usecases related to the > different ways IoT devices are exploited by malicious adversaries to > instantiate Distributed Denial of Services (DDoS) attacks. The attacks > are generted from IoT devices that have no proper protection against > generating unsolicited communication messages targeting a certain > network and creating large amounts of network traffic. The attackers > take advantage of breaches in the configuration data in unprotected I= oT > devices exploited for DDoS attacks. The attackers take advantage of t= he > IoT devices that can send network packets that were generated by > malicious code that interacts with an OS implementation that runs on > the IoT devices. The prupose of this draft is to present possible IoT > DDoS usecases that need to be prevented by TEE. The major enabler of > such attacks is related to IoT devices that have no OS or unprotected > EE OS and run code that is downloaded to them from the TA and modified > by man-in-the-middle that inserts malicious code in the OS. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=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. > The IETF Secretariat > _______________________________________________ Secdispatch mailing > list Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4oxxkACgkQgItw+93Q 3WUTHwf/ZA1c8Q8XjIHvfxWsYSubtc6CnNfvaE5wv1pfZC0rbwb7M3qD/4xCdd0H cHd30sc8Koa6/j95hA1F+q1EuegWsCH3+c3aNx+6zylsrhYfCx9pbJPPhdxfiEFe VLySNOYM5a86SXEFakB5kJ8+WmlLvacqMB5EhXljmhvpzlo+frkLP2mUXEujXeFi XJo8GXaeei4RlXH4h6ua/CXwzpsWWn/O13dUkcAkmwtKxa648dAKugBB1umJB+Xz PJ5MvlfXLzcgSkHUh5pQaFwddgeX1Vs2EMlYWbWU3+sStvEFBe5WE2tLIqbJmLhJ kDZFneoHOaubj+CLCZSU7RTyo3oWGQ== =I48L -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 23 15:22:20 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F7C1200F9 for ; Thu, 23 Jan 2020 15:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR-0P4Djdgqo for ; Thu, 23 Jan 2020 15:22:18 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4AB0A1200BA for ; Thu, 23 Jan 2020 15:21:56 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00NNLpRh027012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jan 2020 18:21:54 -0500 Date: Thu, 23 Jan 2020 15:21:51 -0800 From: Benjamin Kaduk To: "Markku-Juhani O. Saarinen" Cc: Eric Rescorla , Michael Richardson , IETF SecDispatch Message-ID: <20200123232151.GA90660@kduck.mit.edu> References: <052d3ee0-41ae-c4f4-7013-6286942c468a@cs.tcd.ie> <3140.1579364674@localhost> <15967.1579382030@localhost> <24181.1579453158@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Can Composite sigs move back to LAMPS? X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 23:22:19 -0000 On Mon, Jan 20, 2020 at 02:40:15PM +0000, Markku-Juhani O. Saarinen wrote: > > A couple of additional technical points: > - The reason why I mentioned SHA3/SHAKE for RSA and ECC is that this would > seem to allow message hashing to be performed only once, rather than twice > (at least for Dilithium and Falcon). > - We don't see this as being as widely used for TLS server authentication > as for smart cards, secure elements and similar applications that can't > just switch or negotiate certificate chains on the fly. I work on the > hardware side myself and especially there we have additional considerations > such as hardcoded cert chains and FIPS certification, which is currently > only available for the hybrid case. I wouldn't want to leave the issuance > of OIDs for this purpose at the mercy of TLS folks, which is just one of > many applications of this format. Isn't that the point of OIDs, though, that no one is at the mercy of anyone else, and can just mint their own OIDs as needed? -Ben