<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
When I started to write the ECDSA code for engine_pkcs11 in 2011
the code to support the method hooks was not<br>
in the code. So I used internal OpenSSL header files to copy the
ECDSA_METHOD and replace the function needed. <br>
Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did
OpenSSL support the needed calls to hook ECDSA.<br>
They did not add the hooks for ECDH. <br>
<br>
If you can't wait then you have to do it your self. *YOU* could do
the same thing for ECDH. But your code would only <br>
be good for 1.0.2 because the whole way of doing EC methods changes
in 1.1. <br>
<br>
I believe Alexander said he had changes to OpenSSL, which is another
approach. <br>
He has said there were here:
<a class="moz-txt-link-freetext" href="https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches">https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches</a><br>
<br>
You could also hire someone who could do more then: "test it and
offer minor enhancements".<br>
(And not me. I am taking the 1.1 approach to getting ECDH. working
in engine.) <br>
<br>
<div class="moz-cite-prefix">On 1/20/2016 2:19 PM, Blumenthal, Uri -
0553 - MITLL wrote:<br>
</div>
<blockquote
cite="mid:20160120201925.17788998.82513.46556@ll.mit.edu"
type="cite">
<div style="width: 100%; font-size: initial; font-family: Calibri,
'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align:
initial; background-color: rgb(255, 255, 255);">Very possible
that I'm missing the point here.</div>
<div style="width: 100%; font-size: initial; font-family: Calibri,
'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align:
initial; background-color: rgb(255, 255, 255);"><br>
</div>
<div style="width: 100%; font-size: initial; font-family: Calibri,
'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align:
initial; background-color: rgb(255, 255, 255);">Still, since
openssl-1_0_2 does ECDH, and it exposes ECDSA to external
engine(s), how difficult would it be to add ECDH exposure? I
suspect - a good deal easier than getting 1.1 replace 1.0.x as
the de-facto deployment standard.</div>
<div style="width: 100%; font-size: initial; font-family: Calibri,
'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align:
initial; background-color: rgb(255, 255, 255);"><br>
</div>
<div style="width: 100%; font-size: initial; font-family: Calibri,
'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align:
initial; background-color: rgb(255, 255, 255);">Plus, by this
time there already are (and reasonably common) tokens that
support ECDH, other packages that do ECDH, and people (like
myself :-) willing to test it and offer minor enhancements.</div>
<div style="width: 100%; font-size: initial; font-family: Calibri,
'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align:
initial; background-color: rgb(255, 255, 255);"><br>
</div>
<div style="width: 100%; font-size: initial; font-family: Calibri,
'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align:
initial; background-color: rgb(255, 255, 255);">Another point I
seem to be missing - if what's necessary to implement ECDH in an
external engine is missing from 1_0_2 - how could Alexander
write a (presumably) working ECDH engine for 1_0_2? If he could
do it, why can't engine_pkcs11 be extended to do the same?</div>
<div style="width: 100%; font-size: initial; font-family: Calibri,
'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align:
initial; background-color: rgb(255, 255, 255);"><br>
</div>
<div style="font-size: initial; font-family: Calibri, 'Slate Pro',
sans-serif; color: rgb(31, 73, 125); text-align: initial;
background-color: rgb(255, 255, 255);">Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div>
<table style="background-color:white;border-spacing:0px;"
width="100%">
<tbody>
<tr>
<td colspan="2" style="font-size: initial; text-align:
initial; background-color: rgb(255, 255, 255);">
<div style="border-style: solid none none;
border-top-color: rgb(181, 196, 223); border-top-width:
1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB
Alpha Sans', 'Slate Pro'; font-size: 10pt;">
<div><b>From: </b>Douglas E Engert</div>
<div><b>Sent: </b>Wednesday, January 20, 2016 14:59</div>
<div><b>To: </b><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></div>
<div><b>Reply To: </b><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></div>
<div><b>Subject: </b>Re: [openssl-dev] ECDH engine</div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
<div id="_originalContent" style="background-color: rgb(255, 255,
255);">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not
ECDH to external engines. It took years to even get ECDSA
exposed.
<br>
OpenSSL approach to support this is OpenSSL-1.1 that does a lot
of other things. But that was there approach. Its their package.<br>
>From working package to distribution always takes several
years...<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/20/2016 1:34 PM, Blumenthal,
Uri - 0553 - MITLL wrote:<br>
</div>
<blockquote type="cite"><span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"
style="border-left:#b5c4df 5 solid; padding:0 0 0 5;
margin:0 0 0 5">
<div>
<div>
<div dir="ltr">Probably it was one of the main reasons
why we didn't use pkcs11 for ATECC508A and wrote an
engine instead</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>I still argue with the approach (IMHO nobody needs yet
another limited engine), but constraining ECC additions to
1.1 does not make any sense to me. 1.0.2 is going to be
around for a quite a while. A lot of applications won’t
migrate to 1.1 quickly – a few years would be a
good/reasonable/safe bet. </div>
<div><br>
</div>
<div>To restrict this work to 1.1 means pushing this basic
capability off by (realistically) several years. Most people
can’t/won't deploy openssl-1.1 as long as it interferes with
the majority of the applications they or their OS is using,
is not good. I for one won’t be able to use 1.1 in practice
until it becomes the embraced standard and software such as
Macports port set is moved to support it. I’m 100% sure
there are
<span style="font-weight:bold">many</span> more of us in
this bus, on different OS (e.g., it looks like Ubuntu is
even worse off than Macports).</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"
style="border-left:#b5c4df 5 solid; padding:0 0 0 5;
margin:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Jan 20, 2016 at
11:10 AM, Blumenthal, Uri - 0553 - MITLL
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:uri@ll.mit.edu">uri@ll.mit.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex; border-left:1px #ccc solid;
padding-left:1ex">
<div bgcolor="#FFFFFF"
style="background-color:rgb(255,255,255);
line-height:initial">
<div style="">Are you saying it won't work
on OpenSSL_1_0_2-stable?!</div>
<div style=""><br>
</div>
<div style="">Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div>
<table style="background-color:white;
border-spacing:0px" width="100%">
<tbody>
<tr>
<td colspan="2"
style="font-size:initial;
text-align:initial;
background-color:rgb(255,255,255)">
<div style="">
<div><b>From: </b>Douglas E
Engert</div>
<div><b>Sent: </b>Wednesday,
January 20, 2016 14:07</div>
<div><b>To: </b><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openssl-dev@openssl.org"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Reply To: </b><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openssl-dev@openssl.org"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Subject: </b>Re:
[openssl-dev] ECDH engine</div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
<div
style="background-color:rgb(255,255,255)">Patches
are underdevelopment for OpenSC's libp11
and engine_pkcs11 to support ECDH. There
are waiting for OpenSSL-1.1 to be come
stable<br>
and some minor bug fixes. Testing is
proceeding using OpenSSL-1.1-pre2 today.
OpenSSL-1.1 is needed because it exposes
the functions needed<br>
to use ECDH from an external engine i.e.
the OPenSC engine_pkcs11. <br>
<br>
<a moz-do-not-send="true"
href="https://github.com/OpenSC/libp11/issues/52"
target="_BLANK">https://github.com/OpenSC/libp11/issues/52</a><br>
<a moz-do-not-send="true"
href="https://github.com/dengert/libp11/tree/prep-openssl-1.1"
target="_BLANK">
https://github.com/dengert/libp11/tree/prep-openssl-1.1</a><br>
<a moz-do-not-send="true"
href="https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1"
target="_BLANK">
https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1</a><br>
<br>
In addition to a major rewrite of
combining the ECDSA_METHOD and ECDH_METHOD
into an C_KEY_METHOD, OpenSSL-1.1
introduces a lot of changes,
<br>
mainly because it hides many of the
structures that have been exposed in the
past. This causes a major rewrite of code
to use functions to access these
structures.
<br>
<br>
Although OpenSC could still use an older
version of OpenSSL, there is also underway
changes for OpenSC to use OpenSSL-1.1:<br>
<a moz-do-not-send="true"
href="https://github.com/OpenSC/OpenSC/pull/654"
target="_BLANK">https://github.com/OpenSC/OpenSC/pull/654</a><br>
<a moz-do-not-send="true"
href="https://github.com/dengert/OpenSC/tree/prep-openssl-1.1"
target="_BLANK">https://github.com/dengert/OpenSC/tree/prep-openssl-1.1</a><br>
<br>
<br>
<div>On 1/20/2016 12:02 PM, Blumenthal,
Uri - 0553 - MITLL wrote:<br>
</div>
<blockquote type="cite">
<div style="">I forgot to add that
OpenSSL-1_0-2-stable with the current
(Github master) engine-pkcs11, libp11,
and OpenSC successfully does ECDSA
with keys on the token (tested for
ECC256 and ECC384).</div>
<div style=""><br>
</div>
<div style="">OpenSC tools successfully
derive (i.e., implement ECDH1_DERIVE).
I'm waiting for libp11 and
engine_pkcs11 to add this capability.</div>
<div style=""> </div>
<div style="">Ideally this is where your
code would plug in, and complete the
circle.</div>
<div style=""><br>
</div>
<div style="">As it currently is, a
separate Atmel-specific ECC-specific
engine is of a limited usefulness.</div>
<div style=""><br>
</div>
<div style="">Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div>
<table style="background-color:white;
border-spacing:0px" width="100%">
<tbody>
<tr>
<td colspan="2"
style="font-size:initial;
text-align:initial;
background-color:rgb(255,255,255)">
<div>
<div><b>From: </b>Blumenthal,
Uri - 0553 - MITLL</div>
<div><b>Sent: </b>Wednesday,
January 20, 2016 12:46</div>
<div><b>To: </b><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openssl-dev@openssl.org"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Reply To: </b><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openssl-dev@openssl.org"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Subject: </b>Re:
[openssl-dev] ECDH engine</div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
<div><span>
<blockquote
style="border-left:#b5c4df 5
solid; padding:0 0 0 5; margin:0 0
0 5">
<div>
<div dir="auto">
<div>The ATECC508A is a chip.
There are few USB devices
built by Atmel on its base.
Or you can use the chip
directly over I2C (that many
people like to do). You can
follow the links that we
posted on the ATECCX08
Engine repository WiKi to
learn about the chip. </div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>I see, thanks.</div>
<div><br>
</div>
<span>
<blockquote
style="border-left:#b5c4df 5
solid; padding:0 0 0 5; margin:0 0
0 5">
<div>
<div dir="auto">
<div>Well, our first indent
was to use the pksc11
library. But it didn't go to
well for many reasons. I
should go back for several
months to collect these
reasons but I think the main
reason was that ATECC508A
hardware is based on ECC-256
algorithms while pkcs11 is
originally written for RSA -
the overhead was looking too
high (many ATECC508
customers are using limited
hardware and want direct I2C
connection to the chip). </div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>There are a few hardware tokens
(USB-pluggable), e.g. Yubikey, that
support ECC256 and (in case of
Yubikey 4) ECC384.</div>
<div><br>
</div>
<span>
<blockquote
style="border-left:#b5c4df 5
solid; padding:0 0 0 5; margin:0 0
0 5">
<div>
<div dir="auto">
<div>But let's talk about
pkcs11. Can you point me to
the set of documentation for
EC-DERIVE? It may be a good
time now to add the ATECC508
support to there.</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>Honestly, I’m more interested in
adding ECDH support – assuming that
it would also serve ATECC508, rather
than working on ATECC508B and hoping
that perhaps it would be usable for
other ECC-capable tokens.</div>
<div><br>
</div>
<div>Here’s the PKCS#11 spec <a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf"
target="_BLANK"><a class="moz-txt-link-freetext" href="http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf">http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf</a></a>,
which covers ECDH including
ECDH1_DERIVE and ECDH1<span
style="font-style:italic">_</span>COFACTOR_DERIVE.
I think older versions (like v2.20)
have more content, but this is the
current one.</div>
<div><br>
</div>
<div>Hope it helps.</div>
<div><br>
</div>
<div>P.S. At this time I’m standing by
my original opinion – that a better
way is incorporating ECDH1_<span
style="font-style:italic">*</span>DERIVE
in libp11 and engine<span
style="font-style:italic">_</span>pkcs11,
rather than creating an engine
specifically for one chip that add
uncertainly of non-interoperability
with other chips/tokens.</div>
<div><br>
</div>
<div><br>
</div>
<span>
<blockquote
style="border-left:#b5c4df 5
solid; padding:0 0 0 5; margin:0 0
0 5">
<div>
<div dir="auto">
<div>On Jan 20, 2016, at 8:11
AM, Blumenthal, Uri - 0553 -
MITLL <<a
moz-do-not-send="true"
href="mailto:uri@ll.mit.edu"><a class="moz-txt-link-abbreviated" href="mailto:uri@ll.mit.edu">uri@ll.mit.edu</a></a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div style="">What is this
Atmel x508x? Is it a
chip? Is it a
token/smartcard? Is it
accessible via PKCS#11
at all? Is it accessible
by/via OpenSC?</div>
<div style=""><br>
</div>
<div style="">I am trying
to figure why such a
generic and useful set
of ECC operations (Sign,
Derive) is
implementation-limited
to one single
<whatever>. </div>
<div style=""><br>
</div>
<div style="">A much
better solution to me
would be adding
EC-DERIVE to
engine_pkcs11, and
automatically get all
the tokens covered.</div>
<div style=""><br>
</div>
<div style="">Since I'm
probably missing
something, could you
please educate me?</div>
<div style=""><br>
</div>
<div style="">Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div>
<table
style="background-color:white;
border-spacing:0px"
width="100%">
<tbody>
<tr>
<td colspan="2"
style="font-size:initial;
text-align:initial;
background-color:rgb(255,255,255)">
<div>
<div><b>From: </b>Alexander
Gostrer</div>
<div><b>Sent: </b>Wednesday,
January 20,
2016 10:47</div>
<div><b>To: </b>Dr.
Stephen Henson</div>
<div><b>Reply
To: </b><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Cc: </b><a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:openssl-dev@openssl.org"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Subject:
</b>Re:
[openssl-dev]
ECDH engine</div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>Hi Steve,<br>
</div>
And here is the
ENGINE
implementation
for Atmel
ATECC508A with
few small
patches to
OpenSSL_1_0_2-stable:<br>
<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/AtmelCSO/cryptoauth-openssl-engine"
target="_BLANK"><a class="moz-txt-link-freetext" href="https://github.com/AtmelCSO/cryptoauth-openssl-engine">https://github.com/AtmelCSO/cryptoauth-openssl-engine</a></a><br>
<br>
</div>
Your comments are
welcome.<br>
<br>
</div>
Regards,<br>
</div>
Alex.<br>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Sat, Dec 19, 2015
at 12:49 PM, Dr.
Stephen Henson <span
dir="ltr">
<<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated" href="mailto:steve@openssl.org"><a class="moz-txt-link-abbreviated" href="mailto:steve@openssl.org">steve@openssl.org</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0 .8ex;
border-left:1px
#ccc solid;
padding-left:1ex">
On Fri, Dec 18,
2015, Alexander
Gostrer wrote:<br>
<br>
> Hi Steve,<br>
><br>
> John and I
completed
writing an ECDH
engine based on
the<br>
>
OpenSSL_1_0_2-stable
branch. We were
planning to
expand it to the
master<br>
> but found
some major
changes made by
you recently.
What is the
status of<br>
> this task?
Is it stable
enough to follow
it? Are you
planning another<br>
> changes? Is
there a design
document that we
can use in our
work?<br>
><br>
<br>
The version in
master shouldn't
change much any
more.
Documentation
will be<br>
available in the
near future. The
changes were
meant to remove
some of the<br>
weird "quirks"
of ECC compared
to other
algortihms and
to permit future<br>
expansion to a
wider range of
curves.<br>
<br>
In the meantime
it shouldn't be
too hard to
follow how the
new code works.<br>
Instead of
separate
ECDH/ECDSA
methods with
weird locking
and ex_data and<br>
minimal ENGINE
support
everything is
combined into a
single
EC_KEY_METHOD<br>
which can
contain ECDSA,
ECDH and key
generation
(something which
was<br>
impossible with
the old code)
and be tied
directly to an
ENGINE.<br>
<br>
Most of the
primary APIs
such as
ECDH_compute_key
can be
redirected
directly<br>
through an
engine supplied
function in
EC_KEY_METHOD.<br>
<br>
Having said that
the code is very
new and may have
the odd bug that
needs to<br>
be fixed. If you
have any
problems let me
know and I'll
look into them.<br>
<br>
Steve.<br>
--<br>
Dr Stephen N.
Henson. OpenSSL
project core
developer.<br>
Commercial tech
support now
available see: <a
moz-do-not-send="true" href="http://www.openssl.org" rel="noreferrer"
target="_BLANK">
</a><a
moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://www.openssl.org"
target="_BLANK"><a class="moz-txt-link-freetext" href="http://www.openssl.org">http://www.openssl.org</a></a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>openssl-dev mailing
list</span><br>
<span>To unsubscribe: <a
moz-do-not-send="true"
href="https://mta.openssl.org/mailman/listinfo/openssl-dev"
target="_BLANK">
</a><a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://mta.openssl.org/mailman/listinfo/openssl-dev"
target="_BLANK"><a class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a></a></span><br>
</div>
</blockquote>
</div>
</div>
</blockquote>
</span><br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
openssl-dev mailing list
To unsubscribe: <a moz-do-not-send="true" href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_BLANK">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><span class="HOEnZb"></span></pre>
<span class="HOEnZb"></span></blockquote>
<span class="HOEnZb"><font color="#888888"><br>
<pre cols="200">--
Douglas E. Engert <a moz-do-not-send="true" href="mailto:DEEngert@gmail.com"><DEEngert@gmail.com></a>
</pre>
<br>
</font></span></div>
</div>
<br>
_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a moz-do-not-send="true"
href="https://mta.openssl.org/mailman/listinfo/openssl-dev"
rel="noreferrer" target="_BLANK">
https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</span><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
openssl-dev mailing list
To unsubscribe: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_BLANK">https://mta.openssl.org/mailman/listinfo/openssl-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="200">--
Douglas E. Engert <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:DEEngert@gmail.com"><DEEngert@gmail.com></a>
</pre>
<br>
<!--end of _originalContent --></div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
openssl-dev mailing list
To unsubscribe: <a class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="200">--
Douglas E. Engert <a class="moz-txt-link-rfc2396E" href="mailto:DEEngert@gmail.com"><DEEngert@gmail.com></a>
</pre>
</body>
</html>