<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Yup, I also think 25519 should be allowed by the S/MIME BRs, more or less for the reasons Dimitris stated.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Smcwg-public <smcwg-public-bounces@cabforum.org> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Smcwg-public<br><b>Sent:</b> Thursday, June 3, 2021 3:04 AM<br><b>To:</b> Corey Bonnell <Corey.Bonnell@digicert.com>; SMIME Certificate Working Group <smcwg-public@cabforum.org><br><b>Subject:</b> Re: [Smcwg-public] IETF LAMPS discussion re SMIME sample certs<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On 3/6/2021 12:40 π.μ., Corey Bonnell wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Do we know which mail clients support EdDSA? Fleshing out the SBRs with the relevant bits from RFC 8410 seems straightforward enough, but I’m wondering if it won’t be used in practice due to lack of client application support.<o:p></o:p></p></blockquote><p class=MsoNormal><br>Section 2.2 of RFC8551 (S/MIME 4.0) states that receiving agents MUST support EdDSA with curve25519 using PureEdDSA mode and sending agents MUST support at least one of the following algorithms: ECDSA with curve P-256 and SHA-256, or EdDSA with curve25519 using PureEdDSA mode. <br><br>Additionally, section 2.3 states that both sending and receiving clients MUST support ECDH ephemeral-static mode for X25519 using HKDF-256 for the KDF.<br><br>Therefore, we (HARICA) believe that the BRs should not be a blocking factor for innovation by prohibiting the use of a modern, secure cryptographic algorithm. I guess it's a chicken-egg problem. If there are blocking factors, nobody will attempt to implement. Obviously I don't have any strong feelings at this time, just thought to share HARICA's thoughts with the larger group.<br><br><br>Dimitris.<br><br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Smcwg-public <a href="mailto:smcwg-public-bounces@cabforum.org"><smcwg-public-bounces@cabforum.org></a> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Smcwg-public<br><b>Sent:</b> Wednesday, June 2, 2021 5:36 AM<br><b>To:</b> <a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a><br><b>Subject:</b> Re: [Smcwg-public] IETF LAMPS discussion re SMIME sample certs<o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><br>I would recommend allowing EdDSA in the S/MIME BRs.<br><br>Dimitris.<o:p></o:p></p><div><p class=MsoNormal>On 18/5/2021 4:12 μ.μ., Stephen Davidson via Smcwg-public wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>FYI – a selection of text SMIME certs, and related discussion.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><a href="https://mailarchive.ietf.org/arch/msg/spasm/ZJi4W5vYuOf-pzL-TBGUV419yM4/">https://mailarchive.ietf.org/arch/msg/spasm/ZJi4W5vYuOf-pzL-TBGUV419yM4/</a><o:p></o:p></p><p class=MsoNormal>This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Title : S/MIME Example Keys and Certificates<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Author : Daniel Kahn Gillmor<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Filename : draft-ietf-lamps-samples-03.txt<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Pages : 36<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Date : 2021-05-14<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Abstract:<o:p></o:p></p><p class=MsoNormal> The S/MIME development community benefits from sharing samples of<o:p></o:p></p><p class=MsoNormal> signed or encrypted data. This document facilitates such<o:p></o:p></p><p class=MsoNormal> collaboration by defining a small set of X.509v3 certificates and<o:p></o:p></p><p class=MsoNormal> keys for use when generating such samples.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>The IETF datatracker status page for this draft is:<o:p></o:p></p><p class=MsoNormal><a href="https://datatracker.ietf.org/doc/draft-ietf-lamps-samples/">https://datatracker.ietf.org/doc/draft-ietf-lamps-samples/</a><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Smcwg-public mailing list<o:p></o:p></pre><pre><a href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><o:p></o:p></pre></blockquote><p class=MsoNormal> <o:p></o:p></p></blockquote><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>