From nobody Mon Oct 14 18:29:26 2019 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 1176F1200E6 for ; Mon, 14 Oct 2019 18:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 cOpcanBqXuz1 for ; Mon, 14 Oct 2019 18:29:21 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id ECF7D120013 for ; Mon, 14 Oct 2019 18:29:20 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id AE3713741074 for ; Tue, 15 Oct 2019 01:29:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kaV_yXkqblqh for ; Mon, 14 Oct 2019 21:29:18 -0400 (EDT) Received: from Maxs-MacBook-Pro-2.local (unknown [73.95.134.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id ACCD23740C3E for ; Mon, 14 Oct 2019 21:29:18 -0400 (EDT) To: secdispatch@ietf.org References: <28224.1568427573@dooku.sandelman.ca> <5F8D32EB-CE27-4ECD-997F-D0AAE4B798B5@akamai.com> <2b87f695-314c-5aed-14a4-9877fe254161@ericsson.com> <3cfa21d8-efe2-1a69-5268-0a39e9171fe1@cs.tcd.ie> <8e67edddf9154537b438db96ac86e2f8@PMSPEX05.corporate.datacard.com> From: "Dr. Pala" Message-ID: <2589002f-73f6-db84-749a-135ddf3cc4a3@openca.org> Date: Mon, 14 Oct 2019 19:29:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <8e67edddf9154537b438db96ac86e2f8@PMSPEX05.corporate.datacard.com> Content-Type: multipart/alternative; boundary="------------1768C5AB05CB95637C0A175A" Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] [EXTERNAL]Re: Problem statement for post-quantum multi-algorithm PKI 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, 15 Oct 2019 01:29:24 -0000 This is a multi-part message in MIME format. --------------1768C5AB05CB95637C0A175A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi All, I would like to resume some discussion around the proposed solution for defining a new public key and signature format where the internal structure is a SEQUENCE of what has been defined so far - e.g., RSA, ECDSA, XMMS, etc. In particular, I think there are distinct aspects of the problem that need to be addressed separately. Each of these sub-problems are important and need to be investigated. The aspect we are focusing the work on, today, is actually the Engineering/Operational part. In particular, I see three distinct aspects of the problem: * *Post-Quantum Cryptography (PQC).* This relates to studying new algorithms that can be quantum (and non-quantum) safe. This requires years of work and it is a process that NIST already started. We are NOT addressing this problem (out of scope). * *Algorithms (e.g., TLS) behavior with PQC.* This relates to how current protocols handle Post-Quantum Cryptography. In particular, if we were to adopt one of PQC available today, how would TLS perform ? How would other protocols that leverage PKIX perform ? We are NOT addressing this problem (out of scope). * *How to Deploy Algorithms in today's PKIs (Engineering/Operations).* This relates to how can we deploy the new algorithms. In a mixed environment where you do not know if the new algorithms are already sound while the older algorithms are not broken yet, being able to protect with multiple algorithms the different parts of a PKIX is needed today. This proposal is about solving this problem: protecting infrastructures today with multiple algorithms (at least for Root and CA levels) and allow devices to update their support for the intended algorithm in stages - first the older algorithm can be used, then the newer algorithm can be used to validate certificates, then the EE cert algorithm itself can be updated to support signing with the newer algorithm (this is when you can start using the new algorithm by itself). For the specific technical details, /*the proposed solution can actually be used to protect the different data structures in PKIX*/, therefore making it _/economically feasible/_ to keep trusting your current Trust Infrastructures - it does not only apply today to "Traditional" vs. "Post-Quantum" cryptography, but it can be used every time you might want to support more than one algorithm because of security or efficiency (e.g., we can provide an RSA/ECDSA mixed infrastructure - older devices that support RSA will use that algorithm to validate the chain and revocation info, newer devices that support ECDSA will use that algorithm instead). Other possibilities (e.g., using separate certificate chains), IMO, complicate PKIX operations - i.e., now when revoking a certificate we need to be sure we revoke all the corresponding certificates in the sister chains, thus introducing operational costs and procedures (that are not supported by the Ops teams today). I do like this technical solution because it allows me to extend the lifetime of my Trust Infrastructure beyond the "Factorization Doom's Day" - this provides me with the tool I need to make sure all of us are still protected when getting on your broadband network :D It is not just a "Post Quantum Crypto" tool. I would also welcome any other technical solution that provides the same level of backward compatibility and extensible: a solution that will allow me to keep trusting my infrastructure today and let me switch to a newer protocol tomorrow without having to change my authentication procedures (i.e., both validating credentials and their revocation status) tomorrow. Last but not least, /*adopting this idea does not mean we cannot work on the other two important aspects of the problem*/ or that a completely new method for authentication (like Steve Farrell or Phillip Baker suggested) can be investigated - we need to start somewhere and I think this is a very good starting point :D Other approaches might require multiple years to be discussed, therefore I would suggest we work on this first and address the remaining problems in some other venues and/or when we have a proposed solution for them. Does that make sense ? Cheers, Max On 9/16/19 3:37 PM, Mike Ounsworth wrote: > Hi Stephen, > > I feel like we're arguing in circles here and not making any progress. > > > > Re: figuring out "hybrid signature authentication" in parallel with NIST; > You seem to be implying that we can't work on defining message structures to hold multiple keys and signatures until we know the exact encodings of the NIST winners. I'm not sure I follow the reason why. > > Currently, something like, for example, CMS (RFC 5652) is abstracted away from the encodings of a given algorithm; an algorithm can choose any method it wishes to turn its public key and signature into an octet string; how it does it is an internal detail of the algorithm and has no bearing on the CMS spec. This is abstraction between protocol and crypto is a core part of crypto agility. Surely we can start thinking about how to properly combine multiple signatures before we know exactly what those signatures will be. > > > > Re: "Why X.509?" > You seem to be expecting me to justify why X.509 is worth keeping. > I'm expecting you to propose an alternative and justify why it's better. > We're at a stalemate. > > Since X.509 is the accepted standard, I think the ball's in your court here to justify why it should be binned. > > > - - - > Mike Ounsworth | Office: +1 (613) 270-2873 > > -----Original Message----- > From: Secdispatch On Behalf Of Stephen Farrell > Sent: Monday, September 16, 2019 3:59 PM > To: secdispatch@ietf.org > Subject: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI > > > Hiya, > > Replying to various folks at once... > > On 15/09/2019 15:29, Ira McDonald wrote: >> Hi, >> >> Thanks for the link to Kenny's talk. >> >> Stephen - The hard problem for automotive vehicles is that, even if >> Quantum Computing never comes to pass, algorithms and various >> implementations go on having new weaknesses found over time. >> But decent performance requires hardware assist, in many cases. >> But automotive ECUs are very unlikely to start have large FPGAs added >> soon. Replacing 100s of expensive ECUs in fielded vehicles to allow >> practical algorithm agility is not going to happen. This issue that >> Michael Richardson mentioned is at the top of the list for the >> automotive cybersecurity community. > I don't understand how devices that are not going to be updated can support algorithm agility. Perhaps you mean that you want to deploy those devices soon and not update for a couple of decades or something? If so, that sound like a bad plan to me, and one that'd be better to not cater to really. (RFC8240 has lots of discussion of that.) > > > On 16/09/2019 17:05, Mike Ounsworth wrote: >> My Goal: multi-vendor interop on PQ certificates. > That seems to beg the question again as to why x.509 is needed at all as part of a PQ solution. > >> I'm coming from the >> perspective of a CA; it can take years to distribute a root cert to >> all the places it needs to be before you can really start using it. >> Plus, people want to playing with these things ASAP to understand the >> scope of infrastructure changes required. There's the time pressure. >> >> I think you're right that to really deploy any meaningful 20 year root >> using, for example the small lattice schemes, we'll need to wait for >> the NIST PQC algs to stop having so much churn. >> >> That said, laying the groundwork for the "hybrid" property in >> certificates that the NIST PQC community is calling for will require >> much debate and a few RFCs. This work is necessary and independent of >> the choice of algorithm from the NIST PQC competition, so why should >> we wait until 2023 to _start_ thinking about it? Why not do it in >> parallel, be able to offer alpha test versions of PKI products before >> the conclusion of the NIST PQC, and be ready to drop-in the NIST >> winners the day they're ready? > One reason to not do it in parallel is that we don't know how the winning algorithm parameters will look. I can easily imagine NIST modifying how those are encoded and/or introducing new variations, after basic algorithms have been picked, leading to things having to be re-done. > > (Sorry if the quoting is messed up below, if so, it was messed up in my MUA before I started is my excuse:-) On 16/09/2019 19:06, Daniel Van Geest wrote: >> Can we support multiple signatures inside a certificate? I don't think >> so. >> >> Why not? Mike’s problem statement draft has two potential technical >> solutions doing just that, each with advantages and disadvantages. >> Or is there more of a logistical or other issue? Knowing why you >> think we can’t support multiple signatures inside a certificate could >> help refine the problem statement. > Again, that assumes that x.509 is a sensible part of a solution. > We should first question that. (Mike's draft [1] doesn't.) > > Secondly, even if x.509 additions were useful somehow for backwards compatibility (which I find hard to believe TBH) then dealing with >> 1 certificate is likely far easier than messing about inside certs > and thereby breaking all the lovely/horrible x.509 code out there. > So Mike's section 2.1 [1] is way easier than the 2.[2|3] approaches, despite it being the one with no specific drafts. > > Again, all that said, I do understand why it may be attractive for those who produce certificates to argue for putting the PQ magic beans inside x.509. There are costs elsewhere implied in doing that, so it ought not be a starting-out assumption. > > I don't consider the question as to why a PQ x.509 is needed nor why now has been satisfactorily answered so far. > > Cheers, > S. > > [1] https://tools.ietf.org/html/draft-pq-pkix-problem-statement > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------1768C5AB05CB95637C0A175A Content-Type: multipart/related; boundary="------------8706AA7D7D6ED1F65B95D56F" --------------8706AA7D7D6ED1F65B95D56F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi All,

I would like to resume some discussion around the proposed solution for defining a new public key and signature format where the internal structure is a SEQUENCE of what has been defined so far - e.g., RSA, ECDSA, XMMS, etc.

In particular, I think there are distinct aspects of the problem that need to be addressed separately. Each of these sub-problems are important and need to be investigated. The aspect we are focusing the work on, today, is actually the Engineering/Operational part.

In particular, I see three distinct aspects of the problem:

  • Post-Quantum Cryptography (PQC). This relates to studying new algorithms that can be quantum (and non-quantum) safe. This requires years of work and it is a process that NIST already started. We are NOT addressing this problem (out of scope).

  • Algorithms (e.g., TLS) behavior with PQC. This relates to how current protocols handle Post-Quantum Cryptography. In particular, if we were to adopt one of PQC available today, how would TLS perform ? How would other protocols that leverage PKIX perform ? We are NOT addressing this problem (out of scope).

  • How to Deploy Algorithms in today's PKIs (Engineering/Operations). This relates to how can we deploy the new algorithms. In a mixed environment where you do not know if the new algorithms are already sound while the older algorithms are not broken yet, being able to protect with multiple algorithms the different parts of a PKIX is needed today. This proposal is about solving this problem: protecting infrastructures today with multiple algorithms (at least for Root and CA levels) and allow devices to update their support for the intended algorithm in stages - first the older algorithm can be used, then the newer algorithm can be used to validate certificates, then the EE cert algorithm itself can be updated to support signing with the newer algorithm (this is when you can start using the new algorithm by itself).

For the specific technical details, the proposed solution can actually be used to protect the different data structures in PKIX, therefore making it economically feasible to keep trusting your current Trust Infrastructures - it does not only apply today to "Traditional" vs. "Post-Quantum" cryptography, but it can be used every time you might want to support more than one algorithm because of security or efficiency (e.g., we can provide an RSA/ECDSA mixed infrastructure - older devices that support RSA will use that algorithm to validate the chain and revocation info, newer devices that support ECDSA will use that algorithm instead).

Other possibilities (e.g., using separate certificate chains), IMO, complicate PKIX operations - i.e., now when revoking a certificate we need to be sure we revoke all the corresponding certificates in the sister chains, thus introducing operational costs and procedures (that are not supported by the Ops teams today).

I do like this technical solution because it allows me to extend the lifetime of my Trust Infrastructure beyond the "Factorization Doom's Day" - this provides me with the tool I need to make sure all of us are still protected when getting on your broadband network :D It is not just a "Post Quantum Crypto" tool.

I would also welcome any other technical solution that provides the same level of backward compatibility and extensible: a solution that will allow me to keep trusting my infrastructure today and let me switch to a newer protocol tomorrow without having to change my authentication procedures (i.e., both validating credentials and their revocation status) tomorrow.

Last but not least, adopting this idea does not mean we cannot work on the other two important aspects of the problem or that a completely new method for authentication (like Steve Farrell or Phillip Baker suggested) can be investigated - we need to start somewhere and I think this is a very good starting point :D Other approaches might require multiple years to be discussed, therefore I would suggest we work on this first and address the remaining problems in some other venues and/or when we have a proposed solution for them.

Does that make sense ?

Cheers,
Max

On 9/16/19 3:37 PM, Mike Ounsworth wrote:
Hi Stephen,

I feel like we're arguing in circles here and not making any progress.



Re: figuring out "hybrid signature authentication" in parallel with NIST; 
You seem to be implying that we can't work on defining message structures to hold multiple keys and signatures until we know the exact encodings of the NIST winners. I'm not sure I follow the reason why.

Currently, something like, for example, CMS (RFC 5652)  is abstracted away from the encodings of a given algorithm; an algorithm can choose any method it wishes to turn its public key and signature into an octet string; how it does it is an internal detail of the algorithm and has no bearing on the CMS spec. This is abstraction between protocol and crypto is a core part of crypto agility. Surely we can start thinking about how to properly combine multiple signatures before we know exactly what those signatures will be.



Re: "Why X.509?"
You seem to be expecting me to justify why X.509 is worth keeping.
I'm expecting you to propose an alternative and justify why it's better.
We're at a stalemate. 

Since X.509 is the accepted standard, I think the ball's in your court here to justify why it should be binned.


- - -
Mike Ounsworth | Office: +1 (613) 270-2873

-----Original Message-----
From: Secdispatch <secdispatch-bounces@ietf.org> On Behalf Of Stephen Farrell
Sent: Monday, September 16, 2019 3:59 PM
To: secdispatch@ietf.org
Subject: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI


Hiya,

Replying to various folks at once...

On 15/09/2019 15:29, Ira McDonald wrote:

Hi,

Thanks for the link to Kenny's talk.

Stephen - The hard problem for automotive vehicles is that, even if 
Quantum Computing never comes to pass, algorithms and various 
implementations go on having new weaknesses found over time.
But decent performance requires hardware assist, in many cases.
But automotive ECUs are very unlikely to start have large FPGAs added 
soon.  Replacing 100s of expensive ECUs in fielded vehicles to allow 
practical algorithm agility is not going to happen.  This issue that 
Michael Richardson mentioned is at the top of the list for the 
automotive cybersecurity community.

I don't understand how devices that are not going to be updated can support algorithm agility. Perhaps you mean that you want to deploy those devices soon and not update for a couple of decades or something? If so, that sound like a bad plan to me, and one that'd be better to not cater to really. (RFC8240 has lots of discussion of that.)


On 16/09/2019 17:05, Mike Ounsworth wrote:

My Goal: multi-vendor interop on PQ certificates.

That seems to beg the question again as to why x.509 is needed at all as part of a PQ solution.


I'm coming from the
perspective of a CA; it can take years to distribute a root cert to 
all the places it needs to be before you can really start using it.
Plus, people want to playing with these things ASAP to understand the 
scope of infrastructure changes required. There's the time pressure.

I think you're right that to really deploy any meaningful 20 year root 
using, for example the small lattice schemes, we'll need to wait for 
the NIST PQC algs to stop having so much churn.

That said, laying the groundwork for the "hybrid" property in 
certificates that the NIST PQC community is calling for will require 
much debate and a few RFCs. This work is necessary and independent of 
the choice of algorithm from the NIST PQC competition, so why should 
we wait until 2023 to _start_ thinking about it? Why not do it in 
parallel, be able to offer alpha test versions of PKI products before 
the conclusion of the NIST PQC, and be ready to drop-in the NIST 
winners the day they're ready?

One reason to not do it in parallel is that we don't know how the winning algorithm parameters will look. I can easily imagine NIST modifying how those are encoded and/or introducing new variations, after basic algorithms have been picked, leading to things having to be re-done.

(Sorry if the quoting is messed up below, if so, it was messed up in my MUA before I started is my excuse:-) On 16/09/2019 19:06, Daniel Van Geest wrote:

Can we support multiple signatures inside a certificate? I don't think 
so.

Why not?  Mike’s problem statement draft has two potential technical 
solutions doing just that, each with advantages and disadvantages.
Or is there more of a logistical or other issue?  Knowing why you 
think we can’t support multiple signatures inside a certificate could 
help refine the problem statement.

Again, that assumes that x.509 is a sensible part of a solution.
We should first question that. (Mike's draft [1] doesn't.)

Secondly, even if x.509 additions were useful somehow for backwards compatibility (which I find hard to believe TBH) then dealing with

1 certificate is likely far easier than messing about inside certs

and thereby breaking all the lovely/horrible x.509 code out there.
So Mike's section 2.1 [1] is way easier than the 2.[2|3] approaches, despite it being the one with no specific drafts.

Again, all that said, I do understand why it may be attractive for those who produce certificates to argue for putting the PQ magic beans inside x.509. There are costs elsewhere implied in doing that, so it ought not be a starting-out assumption.

I don't consider the question as to why a PQ x.509 is needed nor why now has been satisfactorily answered so far.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-pq-pkix-problem-statement
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------8706AA7D7D6ED1F65B95D56F Content-Type: image/png; name="mpoipelcpdmkkcii.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="mpoipelcpdmkkcii.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------8706AA7D7D6ED1F65B95D56F-- --------------1768C5AB05CB95637C0A175A-- From nobody Fri Oct 25 14:14:56 2019 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 1CCA61209AC; Fri, 25 Oct 2019 14:12:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, secdispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203792811.2724.6905163270989642586.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:08 -0700 Archived-At: Subject: [Secdispatch] secdispatch - Requested session has been scheduled for IETF 106 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: Fri, 25 Oct 2019 21:12:14 -0000 Dear Kathleen Moriarty, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. secdispatch Session 1 (2:00 requested) Tuesday, 19 November 2019, Afternoon Session III 1710-1840 Room Name: Padang size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/secdispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Kathleen Moriarty 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 i2nsf ipsecme lamps mile oauth rats sacm secevent suit teep tls tokbind Technology Overlap: httpbis People who must be present: Kathleen Moriarty Roman Danyliw Richard Barnes Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 25 15:14:46 2019 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 471F6120025 for ; Fri, 25 Oct 2019 15:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 WilWWPnOBwb5 for ; Fri, 25 Oct 2019 15:14:43 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20EF9120020 for ; Fri, 25 Oct 2019 15:14:43 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id g81so2600994oib.8 for ; Fri, 25 Oct 2019 15:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=06OTelGBsnUGo/vHm56JP/cuLCzdVpwj92FprohhZP4=; b=jTVGMHZ4CB2EtB48Y3yCuLTSTqh5GgsH+8ARGwRjBnAGAoThTSldEbcFK6ktyd/L70 DxnEnX3iG/OZur1v4vOg7N2AZhc7bIO4cxzqJHbAbgJoFF+M5wTE/xcTfsqs/lU2KDMH vmtZthkviz7NxbMin66qZ0XiG3rL1pCMzAVaIIfkr9aPrnZULDPTf4vUqHhR1+zyw7YE RsUzyUTAfSsAOYR18GrSkE4bn56oqy22u6Qy/4hQcQh/hYBaxzPwOtdSRbDkIG4r02tR Un+jGA5V57+VARuATbW0lNhdKvYN1VH8uVZHdiNKAJ9+fWAW1pjxz22yt2Qg3YDOhtSs n04w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=06OTelGBsnUGo/vHm56JP/cuLCzdVpwj92FprohhZP4=; b=WdOs8lVYaEgxivwNYxphNnTXyjt5uKRWvMmGVZ4NRTD6fLZQmAwT/fMm5w9dP+BUgj b/nPOh2HGKgpl/qhxf4dm5uZCQHMzGi8oz5H5Ba1lwKoUwJb+0zMsdgVR1em5KbhW+qf 3lZbg3xvqd8Udb5SWX9AFV5YVBD8VNyllmvAR6gDOdfUGVZ7gVh2r6tQaZe5x7Pqirj3 w+vMheoMTP8nnv2Kj6R21iimeFTGjEPekxGV/cWlyEKntfkjUylJRv2ZZGJf0imGifTl 3MkwSsxbvNrBXgbwiiZuJ2yNDBdEdJVEFck0f9oT6u6Y6CcOku1B3VgXKuWNh33miI2r vTpA== X-Gm-Message-State: APjAAAUzRHJPgGkz5g1XtOoBZOZ7N/LyMhrxSytoq9z31fcdhHOz59yG WKdns2cPKmAnxzo+WVo4gseyEVUosG6wR+Pj5V11ILdr X-Google-Smtp-Source: APXvYqwQwLw2jvrKZ2IhlimhRhM2KmbbY0fqA8GST0HK0n40MCEVhat/ag7A31qlvJDPLKvQTU185WnzoYD0tZ+rApk= X-Received: by 2002:a54:4187:: with SMTP id 7mr4859487oiy.158.1572041681123; Fri, 25 Oct 2019 15:14:41 -0700 (PDT) MIME-Version: 1.0 From: Kathleen Moriarty Date: Fri, 25 Oct 2019 18:14:05 -0400 Message-ID: To: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000f9c00a0595c37948" Archived-At: Subject: [Secdispatch] Call for Agenda items 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, 25 Oct 2019 22:14:44 -0000 --000000000000f9c00a0595c37948 Content-Type: text/plain; charset="UTF-8" Greetings! If you have proposed work you'd like to present at SecDispatch, please make your request and provide a link to your draft to be discussed in advance. Thank you! -- Best regards, Kathleen --000000000000f9c00a0595c37948 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings!

If you have proposed work yo= u'd like to present at SecDispatch, please make your request and provid= e a link to your draft to be discussed=C2=A0in advance.

Thank you!

--

Best regards,
Kathleen
--000000000000f9c00a0595c37948-- From nobody Mon Oct 28 09:58:17 2019 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 B9E32120113 for ; Mon, 28 Oct 2019 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SCbPZJEiSt46 for ; Mon, 28 Oct 2019 09:58:11 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id C90BE1200F5 for ; Mon, 28 Oct 2019 09:58:11 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 73C0E3741074; Mon, 28 Oct 2019 16:58:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wjiTlE7uyysk; Mon, 28 Oct 2019 12:58:09 -0400 (EDT) Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id C34B33740972; Mon, 28 Oct 2019 12:58:09 -0400 (EDT) To: Kathleen Moriarty , secdispatch@ietf.org References: From: "Dr. Pala" Message-ID: <12e63b21-5d0a-558b-b7ef-fe4b27554bcd@openca.org> Date: Mon, 28 Oct 2019 10:58:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------49869BB19DEE24768A942297" Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] Call for Agenda items 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, 28 Oct 2019 16:58:15 -0000 This is a multi-part message in MIME format. --------------49869BB19DEE24768A942297 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kathleen, All, As you know we have the Composite Crypto  / Post-Quantum draft we would like to present at IETF 106 in Singapore - the link to the github repository is as follows: * https://github.com/EntrustDatacard/draft-ounsworth-composite-sigs Also, another topic that I would like to bring to SecDispatch (mostly for awareness, I guess, at this stage) is how to improve OCSP responses (i.e., by providing range-based responses and full chain status). Although we have not published an I-D yet (but I hope to have a document uploaded soon), there has been some interest on the topic in both LAMPS and PKIX, therefore I was wondering if we could bring it to SecDispatch to get even more feedback and next-steps directions. Here's some reference to the discussion we started in PKIX and LAMPS: * https://mailarchive.ietf.org/arch/msg/pkix/eGE53uJIYKSzu7pObiUGWNXDH3M * https://mailarchive.ietf.org/arch/msg/spasm/Ug_HtJz5FQvLbiXIdGXH---q7N8 Do you think we can get few minutes to bring the topic to SecDispatch (i.e., let's call it OCSPv2 for now) ? Please let us know, Cheers, Max On 10/25/19 4:14 PM, Kathleen Moriarty wrote: > Greetings! > > If you have proposed work you'd like to present at SecDispatch, please > make your request and provide a link to your draft to be discussed in > advance. > > Thank you! > > -- > > Best regards, > Kathleen > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------49869BB19DEE24768A942297 Content-Type: multipart/related; boundary="------------91FECC34782C5CEA9E4EBA04" --------------91FECC34782C5CEA9E4EBA04 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Kathleen, All,

As you know we have the Composite Crypto  / Post-Quantum draft we would like to present at IETF 106 in Singapore - the link to the github repository is as follows:

Also, another topic that I would like to bring to SecDispatch (mostly for awareness, I guess, at this stage) is how to improve OCSP responses (i.e., by providing range-based responses and full chain status). Although we have not published an I-D yet (but I hope to have a document uploaded soon), there has been some interest on the topic in both LAMPS and PKIX, therefore I was wondering if we could bring it to SecDispatch to get even more feedback and next-steps directions.

Here's some reference to the discussion we started in PKIX and LAMPS:

Do you think we can get few minutes to bring the topic to SecDispatch (i.e., let's call it OCSPv2 for now) ?

Please let us know,

Cheers,
Max


On 10/25/19 4:14 PM, Kathleen Moriarty wrote:
Greetings!

If you have proposed work you'd like to present at SecDispatch, please make your request and provide a link to your draft to be discussed in advance.

Thank you!

--

Best regards,
Kathleen

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------91FECC34782C5CEA9E4EBA04 Content-Type: image/png; name="kkbknmaiefjamiic.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="kkbknmaiefjamiic.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------91FECC34782C5CEA9E4EBA04-- --------------49869BB19DEE24768A942297--