From nobody Wed Feb 1 12:29:33 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6AA1299A3 for ; Wed, 1 Feb 2017 12:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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=google.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 pnImqG9_5Vwa for ; Wed, 1 Feb 2017 12:29:29 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 6D78C12956E for ; Wed, 1 Feb 2017 12:29:29 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id w204so241329881oiw.0 for ; Wed, 01 Feb 2017 12:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tt1FeFi6Ru8l2xnAGRAvXXNUctQgQ2kvyQzyraq20bc=; b=TwxWrFUMUGpomqhTbpFgraah1ReQsHJ9ZpfifPIDDp+kG/pxO+kScpcrwAKHskv5C/ y771BQHCVwicga77NRwDJ6j8za5nCX0YQZ2yOLJsmjB2sSX9LN9BLU9WuEzt4QUR9ilA qmQR2zy9m6+IsCovpWQrlHpJ6FMEDz0e35fJtR495WbgX+TASwYuMPj2gVoqp3OWl+ZD NKm1uZUCrC36LyOokwqAL4t3Ozuva00gaMOtkPstOXqoHGUqSl321wklrnux22mUvzX/ BSWVGW2AHDeh6yZ/9WfzdVGmrUNbdOa7rvAOkER0S5M/NnMW1oDm23FTrPmYlBCc/7UC dcNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tt1FeFi6Ru8l2xnAGRAvXXNUctQgQ2kvyQzyraq20bc=; b=M5sG2d052nI2ZSNL/41d0XkUV6KhLTm47nacpqBCa5ahK17BSgVxwBsl4VZBcGtDQF bVu1meRmZWwY1xCRq96ThxqRSTpUCvvjxoghCt/+nTWotT99vqyoua8tlvlseZ5rW/Nt RC8NqyH1gEc2e+KlApjPBFEZET76lwdqirmGeWNdyeAds1nAqn8Fk6oTUvRVbfXroVkh r9MAJTNQVj90lpK4IT+OgxTdx62+M29YyDBkIQQUTS+dEWUzn7AZAut1mkK+doZogONj KZsjdJpU8vZBYSXZ6f6soGmvlKTvGCq/FW5sD4wx8TWR/krOLV/XwPlpsZZ10Qn+JdxJ uaeQ== X-Gm-Message-State: AIkVDXKJBvliplR7Z91TApF1UEDSt+uTHeOh4iyO5nsQPnEXFybwP9VdNEDnv4/LhBZBzAeW9UuU6rkhqR7nSYkh X-Received: by 10.202.75.78 with SMTP id y75mr2073960oia.6.1485980968290; Wed, 01 Feb 2017 12:29:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.49.28 with HTTP; Wed, 1 Feb 2017 12:29:27 -0800 (PST) In-Reply-To: <5C1E3FDBBDDF00121697B1A7@PSB> References: <20170124020138.65213.qmail@ary.lan> <2A6C1E77A2FDB3E4147305EA@PSB> <20170124054212.GF860@mournblade.imrryr.org> <5C1E3FDBBDDF00121697B1A7@PSB> From: Wei Chuang Date: Wed, 1 Feb 2017 12:29:27 -0800 Message-ID: To: SPASM , ietf-dane@dukhovni.org, John C Klensin Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11c161f0c98be405477de793" Archived-At: Subject: [Spasm] Fwd: Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:29:32 -0000 --001a11c161f0c98be405477de793 Content-Type: multipart/alternative; boundary=001a11c161f0c2513c05477de731 --001a11c161f0c2513c05477de731 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I wanted to forward Viktor's proposal below (actually the second proposal) to the Lamps WG for comments. I believe Viktor is proposing minimizing conversion by having PKIX certificates specify the different internationalized forms of email addresses in the same certificate. There's nothing preventing this in the draft, and in fact a similar approach is mentioned for naming constraints. Practically speaking the draft recommends SMTPUTF8 for use with non-ASCII local-part addresses, and rfc822Name for all other email addresses. rfc822Name domain parts support A-label but not U-label. In other words, following recommendation, there isn't much overlap between the two representations. So I don't know if its practical to explicitly call out this suggestion in the draft. Comments? -Wei ---------- Forwarded message ---------- From: John C Klensin Date: Mon, Jan 23, 2017 at 10:05 PM Subject: Re: Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard To: ietf@ietf.org --On Tuesday, January 24, 2017 05:42 +0000 Viktor Dukhovni wrote: >... >> I can argue for the choice of A-labels rather than U-labels >> (or vice versa), but the choice is a matter of taste and I'm >> happy to accept the WG's analysis and decision. > > I also agree that having a single normal form in the > certificate has some merit. I must say that the choice of > U-label as that form is somewhat unexpected given the use of > an A-label normal form with DNS subjectAltNames. Consistency > might have been preferable, though of course the local part > offers no similar representation, and so perhaps the > compelling argument in favour of U-labels is using a > consistent encoding for both parts. Personal opinion: if one gives priority to consistency with DNS subjectAltNames, then it would be best to go with A-labels. If one gives priority to consistency with SMTPUTF8 addresses, especially those containing local-parts with characters in them that lie outside the ASCII repertoire, then one goes with U-labels. If the principal desire is to be consistent with SMTPUTF8 recommendations, then one goes with U-labels too because those specs are fairly clear about not involving email users with A-labels if it can be avoided. As I said, I can argue it either way, but am happy to defer to the WG on this (especially since I strongly suspect they got it right). > This does mean one one will not be able to obtain a useful > certificate for addresses like user@xn--b1adqpd3ao5c.org, > which is what Apple's Mail.app (even in the latest MacOS > Sierra) emits when I configure a sender address in the unicode > form of that domain. My MTA delivers both the U-label and > A-label forms to the same mailbox, but my other (not Mutt) MUA > only sends A-labels. > > Which leads me to the observation that verification software > will already have the message "From:" (or other purported) > signer address in hand, which it will be comparing with the > associated certificate. So it seems far more natural to use > *that* address *verbatim* as the reference identifier to seek > in the certificate. > > One might then obtain a certificates with two email > subjectAltNames: > > * user@xn--b1adqpd3ao5c.org > * user@духовный.org > > which will work regardless of which form is seen in the message > headers, and would not require any conversions by the verifier. > > In other words, check the certificate for whichever address > form appears in the message headers. If that's how the > sending system knows the author, then perhaps it ought to be > good enough in the certificate too! This is a more interesting argument. On the other hand, if that application is ever going to fully support and conform to SMTPUTF8, including local parts that are not entirely in ASCII and non-ASCII header field contents, they are going to need to get over the A-label preference/requirement. What you describe is a plain, ordinary, traditional, use of IDNA by an application that doesn't understand it, not some type of partial SMTPUTF8 implementation. I hope the WG has thought about the two cert option, or will soon, but, if two certificates (potentially issued to different parties unless the CAs are really careful) for what the email system considers the same address poses an attack risk, perhaps "no certs for domains containing any IDN labels" until the relevant mail systems are upgraded" might be a reasonable decision. As Patrik commented about another aspect of the issue, the document really needs to be very clear about these decisions and, ideally, the rationale for them when they might seem questionable... and needs to do it in really clear English. john > This would dramatically simply the implementation, the > application provides the X.509 library with the verbatim > author address and this either matches or does not match the > certificate without any conversions. --001a11c161f0c2513c05477de731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I wanted to forward Viktor's proposal below (actually the second proposal) to the Lamps WG for comments.

I believe Viktor is proposing minimizing conversion by having PKIX certificates specify the different internationalized forms of email addresses in the same certificate.  There's nothing preventing this in the draft, and in fact a similar approach is mentioned for naming constraints.  Practically speaking the draft recommends SMTPUTF8 for use with non-ASCII local-part addresses, and rfc822Name for all other email addresses.  rfc822Name domain parts support A-label but not U-label. In other words, following recommendation, there isn't much overlap between the two representations.  So I don't know if its practical to explicitly call out this suggestion in the draft.  Comments?

-Wei


---------- Forwarded message ----------
From: John C Klensin <john-ietf@jck.com>
Date: Mon, Jan 23, 2017 at 10:05 PM
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
To: ietf@ietf.org




--On Tuesday, January 24, 2017 05:42 +0000 Viktor Dukhovni
<ietf-dane@dukhovni.org> wrote:

>...
>> I can argue for the choice of A-labels rather than U-labels
>> (or vice versa), but the choice is a matter of taste and I'm
>> happy to accept the WG's analysis and decision.
>
> I also agree that having a single normal form in the
> certificate has some merit.  I must say that the choice of
> U-label as that form is somewhat unexpected given the use of
> an A-label normal form with DNS subjectAltNames.  Consistency
> might have been preferable, though of course the local part
> offers no similar representation, and so perhaps the
> compelling argument in favour of U-labels is using a
> consistent encoding for both parts.

Personal opinion: if one gives priority to consistency with DNS
subjectAltNames, then it would be best to go with A-labels.  If
one gives priority to consistency with SMTPUTF8 addresses,
especially those containing local-parts with characters in them
that lie outside the ASCII repertoire, then one goes with
U-labels.  If the principal desire is to be consistent with
SMTPUTF8 recommendations, then one goes with U-labels too
because those specs are fairly clear about not involving email
users with A-labels if it can be avoided.

As I said, I can argue it either way, but am happy to defer to
the WG on this (especially since I strongly suspect they got it
right).

> This does mean one one will not be able to obtain a useful
> certificate for addresses like user@xn--b1adqpd3ao5c.org,
> which is what Apple's Mail.app (even in the latest MacOS
> Sierra) emits when I configure a sender address in the unicode
> form of that domain.  My MTA delivers both the U-label and
> A-label forms to the same mailbox, but my other (not Mutt) MUA
> only sends A-labels.
>
> Which leads me to the observation that verification software
> will already have the message "From:" (or other purported)
> signer address in hand, which it will be comparing with the
> associated certificate. So it seems far more natural to use
> *that* address *verbatim* as the reference identifier to seek
> in the certificate.
>
> One might then obtain a certificates with two email
> subjectAltNames:
>
>     * user@xn--b1adqpd3ao5c.org
>     * user@духовный.org
>
> which will work regardless of which form is seen in the message
> headers, and would not require any conversions by the verifier.
>
> In other words, check the certificate for whichever address
> form appears in the message headers.  If that's how the
> sending system knows the author, then perhaps it ought to be
> good enough in the certificate too!

This is a more interesting argument.  On the other hand, if that
application is ever going to fully support and conform to
SMTPUTF8, including local parts that are not entirely in ASCII
and non-ASCII header field contents, they are going to need to
get over the A-label preference/requirement.  What you describe
is a plain, ordinary, traditional, use of IDNA by an application
that doesn't understand it, not some type of partial SMTPUTF8
implementation.    I hope the WG has thought about the two cert
option, or will soon, but, if two certificates (potentially
issued to different parties unless the CAs are really careful)
for what the email system considers the same address poses an
attack risk, perhaps "no certs for domains containing any IDN
labels" until the relevant mail systems are upgraded" might be a
reasonable decision.

As Patrik commented about another aspect of the issue, the
document really needs to be very clear about these decisions
and, ideally, the rationale for them when they might seem
questionable... and needs to do it in really clear English.

     john


> This would dramatically simply the implementation, the
> application provides the X.509 library with the verbatim
> author address and this either matches or does not match the
> certificate without any conversions.





--001a11c161f0c2513c05477de731-- --001a11c161f0c98be405477de793 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDQQYyGn5KKplH9KajmS50p +VbVOzkvqNNxesNYoWTMEDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAyMDEyMDI5MjhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAhZqLljGutqLfuC6iRp/RNcPNYMN7sPlXHMjo8X2x r8CXv01vjtQuN1Me/6k9RP/xBtUxpyaXsvpF8bmVLI7WhY6poGcI5vMiPTMMYO89/bq/S1pHTqDX cyhf5aK45GWt9u+nW1DPii67rH81AajufWQhQASc+wQEwV4876u7zzHDy8LNXSRQC64e5n8Q1bqd +cK6/R+V0kvR4fSH28+erGYE67LrzhSRfwK/w0ToHvxH2p6DvpQB02Kl20gMHnP3d2ccoBDIM2NX CjNZPe4RJLioMuBBKUomoOMl0tXRHrVHmmfxXoiteafiF3UhrBO++mg8EFkBFrFM+e1cnSQ4BQ== --001a11c161f0c98be405477de793-- From nobody Wed Feb 1 12:34:17 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D411299F2 for ; Wed, 1 Feb 2017 12:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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=google.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 1dYCW9bh_Adm for ; Wed, 1 Feb 2017 12:34:13 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 2AF311299EE for ; Wed, 1 Feb 2017 12:34:13 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id j15so241113261oih.2 for ; Wed, 01 Feb 2017 12:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=b2oaS3Xqsk3J/BrDyzAyyXl7KPqTkOqGGKRjRF94bCU=; b=LaKEfuxIRryPuJvMkOP5m3+S7x9cgBnCUWpClW24zvplS1FXxd/N8+4cp7dYS5OomZ UsNbEYVgHY8RhSdczYOHaNCrn9M1P+VEtBVQINGLxMenGfuMyBHY3GtiZ4wy+21ssVxN cONheGe6knNZt3657lMDvdD9Dtr3YL+Oxsns62PKbl5GgoJSrQkIBHY44rGRAl7Jo49t Zef51VYCAxwu9LIujxgvM4C1ev+eDQHrnzpjSdni7JAQVesVPe9E6cgn0KaXiVs5Xs74 goL8m0Ql6qOAerhNhorJuet11xPRcfhuz8lQchl166e6zYeF9UjSjk9hWMPmcYbvmLo4 lvWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=b2oaS3Xqsk3J/BrDyzAyyXl7KPqTkOqGGKRjRF94bCU=; b=jOBUoo2YwBgu2FVq5ztLS15s2sOMqJEvnI6cSgFJ6fnGGT4WuRSiVtF32qtIEIsef+ YFiYIEJhScja7YPI3kHsurPrig5hesIYriqgN/nvM9ESO0BdVjwbfQhmba3+m0rmhNww FqGMpdhVDxvU7DSTdBWIvvk2SSICbT96RFNtRQ1XVG+WZ06GvsSxl+T3AtSLsakMqd3B 6pk/7FEoyhGqLyguOFGrbC9B2bWUduWixwaksD6TZtHgX68hax7BNwSwMi84FfXs4z8B CgyNzDbrBXvi/ERkc+khqJ2euKBEv832vZY2Yxjz/EymUFm0hraQRiT3MBA/DUaKiAev QcUw== X-Gm-Message-State: AIkVDXLpvh3KuhCpxPyJFaaaePrftttILX+rvyW6Hjf/DMseVLX04x1TDtc3slKvEl1Is0pptYLePqYMC+2+ILzD X-Received: by 10.202.242.8 with SMTP id q8mr2413471oih.129.1485981252229; Wed, 01 Feb 2017 12:34:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.49.28 with HTTP; Wed, 1 Feb 2017 12:34:11 -0800 (PST) In-Reply-To: <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> From: Wei Chuang Date: Wed, 1 Feb 2017 12:34:11 -0800 Message-ID: To: SPASM , Alexey Melnikov , John Klensin Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c092820b5c1c505477df82d" Archived-At: Subject: [Spasm] Fwd: Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:34:15 -0000 --94eb2c092820b5c1c505477df82d Content-Type: multipart/alternative; boundary=94eb2c092820af1e9005477df83f --94eb2c092820af1e9005477df83f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I also wanted to make sure the Lamps WG saw this proposal from last call. The proposal below would mandate that email address domain labels in PKIX certificates must conform to IDNA2008 including [RFC5280] rfc822Name. This too seems reasonable to me, but WG comments? -Wei ---------- Forwarded message ---------- From: Alexey Melnikov Date: Mon, Jan 23, 2017 at 5:40 AM Subject: Re: Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard To: John C Klensin , ietf@ietf.org Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org Hi John, Thank you for your thorough review! My comments/answers below: On 22/01/2017 19:46, John C Klensin wrote: > --On Monday, January 16, 2017 2:45 PM -0800 The IESG > wrote: > > >> (3) A MUST NOT requirement on the use of A-labels has often > been problematic because, as far as a protocol that does not > support IDNA is concerned, they are ordinary labels conforming > to the "preferred syntax" of RFC 1034/1035 (commonly known as > "LDH syntax"). As important, it is easily possible to construct > strings that look (lexically) like A-labels but are actually not > A-labels. If the desire is to prevent the use of anything but > normal (i.e., not IDNA) LDH labels and U-labels, the restriction > that is probably needed is either "no label starting in 'xn--'" > or "no label starting in two letters followed by two > hyphen-minus characters". Requiring NR-LDH restrictions > probably solves the problem (although I'm not sure what "solely > ASCII character labels" means -- see (2) above) but requires > much more specific knowledge of the IDNA2008 protocol set > (particularly RFC 5890 in this case) than I predict readers of > this document will have. See RFC 5890 and 5894 for more > discussion on this issue and other recent correspondence about > confusing and contradictory usage of "IDN" and "IDNA" and the > associated risks for additional details and risk descriptions. > I think this needs to be discussed a bit more in the LAMPS WG, but you have a good point here. > (4) The second paragraph of Section 4 appears to me to be > correct. However, for reasons related to those discussed above, > these are not strictly "conversion" because the operations may > fail (and will fail if the U-labels or A-labels are not strictly > valid). It would probably be useful to be explicit that one of > the effects of this definition is to absolutely prohibit domains > that do not conform to IDNA2008 from appearing in certificates > (IMO, that is A Good Thing). > Yes, I agree this should be said explicitly. --94eb2c092820af1e9005477df83f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I also wanted to make sure the Lamps WG saw this proposal from last call.

The proposal below would mandate that email address domain labels in PKIX certificates must conform to IDNA2008 including [RFC5280] rfc822Name.  This too seems reasonable to me, but WG comments?

-Wei

---------- Forwarded message ----------
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Mon, Jan 23, 2017 at 5:40 AM
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
To: John C Klensin <klensin@jck.com>, ietf@ietf.org
Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org


Hi John,

Thank you for your thorough review! My comments/answers below:



On 22/01/2017 19:46, John C Klensin wrote:
--On Monday, January 16, 2017 2:45 PM -0800 The IESG
<iesg-secretary@ietf.org> wrote:


(3) A MUST NOT requirement on the use of A-labels has often
been problematic because, as far as a protocol that does not
support IDNA is concerned, they are ordinary labels conforming
to the "preferred syntax" of RFC 1034/1035 (commonly known as
"LDH syntax").  As important, it is easily possible to construct
strings that look (lexically) like A-labels but are actually not
A-labels.   If the desire is to prevent the use of anything but
normal (i.e., not IDNA) LDH labels and U-labels, the restriction
that is probably needed is either "no label starting in 'xn--'"
or "no label starting in two letters followed by two
hyphen-minus characters".  Requiring NR-LDH restrictions
probably solves the problem (although I'm not sure what "solely
ASCII character labels" means -- see (2) above) but requires
much more specific knowledge of the IDNA2008 protocol set
(particularly RFC 5890 in this case) than I predict readers of
this document will have.  See RFC 5890 and 5894 for more
discussion on this issue and other recent correspondence about
confusing and contradictory usage of "IDN" and "IDNA" and the
associated risks for additional details and risk descriptions.
I think this needs to be discussed a bit more in the LAMPS WG, but you have a good point here.
(4) The second paragraph of Section 4 appears to me to be
correct.  However, for reasons related to those discussed above,
these are not strictly "conversion" because the operations may
fail (and will fail if the U-labels or A-labels are not strictly
valid).  It would probably be useful to be explicit that one of
the effects of this definition is to absolutely prohibit domains
that do not conform to IDNA2008 from appearing in certificates
(IMO, that is A Good Thing).
 Yes, I agree this should be said explicitly.

 

--94eb2c092820af1e9005477df83f-- --94eb2c092820b5c1c505477df82d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCn4WzQcoovDqysUAGlVH9W ynU3dVTnLr6zrAVsvIh9rTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAyMDEyMDM0MTJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAqDDuPIsTqCR35sF7k/n1jDg+uTpw8OUafWUjV9Xc wv3ogTUWAkKz7wdTFjJndYTDPitYYTS9ZnTAa92KEw9fmb5Xe2VEP9eDfmNlJB41py2AAVGnGXEI zrEzgPMGVmlAk6wHxsYnzD08S5jVJMwVO/6aYWuY+QUo0y7RyKNOdlwVGEVCHRFm5USaq3DAU3T1 D9BqOw82iyVN5zZeWE9Aqbl6qSUuag2jhZX2bAJQPSccdpFiFGHKpMgRPxOBU5nz3urJGDZ7DGYw Ox8aVjYfDeuaacQ9ZtqDqsb/pRwQukTEI6q1FAW/95oMLC/ifISGFsDt20VfsYnfM/I5X3Zomw== --94eb2c092820b5c1c505477df82d-- From nobody Wed Feb 1 15:18:46 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD791295F9 for ; Wed, 1 Feb 2017 15:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 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, RP_MATCHES_RCVD=-3.199, 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=google.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 VYdIW30Dk0Hz for ; Wed, 1 Feb 2017 15:18:42 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 E69281295FE for ; Wed, 1 Feb 2017 15:18:41 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 65so302522784otq.2 for ; Wed, 01 Feb 2017 15:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=92zevhV/gZ/VAQtZUeUnEleCCaP1LbkaIW9VxDQ40d4=; b=RQdRkSm57nfjHJGbP1nz3kyeYYjePnxoaR4xvE/NyiGEG6KlsWGygzTrAHlGexB7k3 53h74SOrzoTuU5RBiVivZl8Ske4yVHGvLM2+I2M8z8TFe7nHQsUeLUt+T4abnuK1YXsq MDcaMljCFXn4P+dBqRCQmj/FywUW7jCbQN9WPlP76ray6Az/Iqh5e78sgJfVIzLqFWGW X5RE2q9HiydCv5bK7Efl+2+PSnZXjgrqAgcs94ywsH77zkNc59SBYnCbE7TBzMXOGGsu eGQAlgI/FaYEeZ73V9bZvqsbRKDJm3Y0pkwsIBA//H23EGPM3PR5ftbfw6+bIMFRah9k lfcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=92zevhV/gZ/VAQtZUeUnEleCCaP1LbkaIW9VxDQ40d4=; b=E0arwI7S18Kz6h/MLKirmSkAuKpW5RSLkNR2g9fEdM7GlEA5dZAGftXzw1Y0TiKTIW A/enNyJpca9UtncCwMispHiFqO4npUZxrNPrEG8t31OCR8eTc1MjxNoMUIh0f0GO3egF 3z/k/m6kcluptWCLyx8G0RlJie7pvESFY2gHQ+fz877G0OCLbkU7X/9IVBiZtnQujI8B Pmh48yno5ItF8qgrm9R+LSQpygandnihCn8wE/0W4EZ7WEOZ1CsJSS0NNHi0Hl2CYDAH UK8IvGFEJJfL1zPHR3N+yfPuRvaqyxzJcbERG9C2+5XMJobx0qhuUNMRUBd5CKN0KnNx /RCA== X-Gm-Message-State: AIkVDXIENLiAyX2LuXv6YvRQJlrg65veRxZ/n/ZJdYmH+Mc7odb6DrsOGi1ff/TCCo7WPj29La0eawGZiRJyxnwb X-Received: by 10.157.22.193 with SMTP id s1mr2593093ots.17.1485991120956; Wed, 01 Feb 2017 15:18:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.49.28 with HTTP; Wed, 1 Feb 2017 15:18:40 -0800 (PST) In-Reply-To: <20170124193109.68919.qmail@ary.lan> References: <20170124193109.68919.qmail@ary.lan> From: Wei Chuang Date: Wed, 1 Feb 2017 15:18:40 -0800 Message-ID: To: SPASM , John Levine Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113e2436ec88260547804432" Archived-At: Subject: [Spasm] Fwd: Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:18:45 -0000 --001a113e2436ec88260547804432 Content-Type: multipart/alternative; boundary=001a113e2436e7d0af05478044aa --001a113e2436e7d0af05478044aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Just to be sure that the Lamps WG sees this, I'm forwarding for comments. In particular this notes a missing step in the existing document to do a case insensitive comparison for the ASCII NR-LDH domain part. This should be added to the document, as should some sort of clarifying domain part setup instructions. -Wei ---------- Forwarded message ---------- From: John Levine Date: Tue, Jan 24, 2017 at 11:31 AM Subject: Re: Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard To: ietf@ietf.org Cc: john-ietf@jck.com >> I reread the spec, which was a good idea. It says the domain >> names can contain U-labels and NR-LDH ASCII labels, which >> seems correct. That forbids both A-labels and dodgy stuff >> that looks like A-labels but isn't. > >Thanks. That is consistent with my impression. My concern is >that the language and terminology won't make it clear about what >is being specified unless someone is _really_ familiar with IDNA >and the "EAI" specs. It meshes with Patrik's concern that the >wording of the spec won't be clear to someone who is not _very_ >good with English. > >My impression is that there is little problem with the intended >underlying spec, but the document text needs some tuning. Agreed. The subsequent section on comparing names would likely benefit from clearer instructions, e.g. a) if the domain contains A-labels, turn them into U-labels b) if the domain still contains R-LDH labels, stop, not a valid name. c) if the domain contains NR-LDH labels, make them all the same case d) do a straight byte comparison of the addresses R's, John --001a113e2436e7d0af05478044aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Just to be sure that the Lamps WG sees this, I'm forwarding for comments.

In particular this notes a missing step in the existing document to do a case insensitive comparison for the ASCII NR-LDH domain part.  This should be added to the document, as should some sort of clarifying domain part setup instructions.

-Wei

---------- Forwarded message ----------
From: John Levine <johnl@taugh.com>
Date: Tue, Jan 24, 2017 at 11:31 AM
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
To: ietf@ietf.org
Cc: john-ietf@jck.com


>> I reread the spec, which was a good idea.  It says the domain
>> names can contain U-labels and NR-LDH ASCII labels, which
>> seems correct.  That forbids both A-labels and dodgy stuff
>> that looks like A-labels but isn't.
>
>Thanks.  That is consistent with my impression.   My concern is
>that the language and terminology won't make it clear about what
>is being specified unless someone is _really_ familiar with IDNA
>and the "EAI" specs.   It meshes with Patrik's concern that the
>wording of the spec won't be clear to someone who is not _very_
>good with English.
>
>My impression is that there is little problem with the intended
>underlying spec, but the document text needs some tuning.

Agreed.  The subsequent section on comparing names would likely
benefit from clearer instructions, e.g.

a) if the domain contains A-labels, turn them into U-labels
b) if the domain still contains R-LDH labels, stop, not a valid name.
c) if the domain contains NR-LDH labels, make them all the same case
d) do a straight byte comparison of the addresses

R's,
John


--001a113e2436e7d0af05478044aa-- --001a113e2436ec88260547804432 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCI6hzGRXt6oknbCpnjHarJ Vd9Tkhg5P2RK3n91Bx55vzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAyMDEyMzE4NDFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAi80ivkSL9V8Ffq/evY35bxVnGpEgN+BdSDuqzP/Z yHtf1whIolgiUs6Q2gseq5UjOWLldG5U5c5jivyxyBSOuuyV0akPLg8RpijH5IJlxRvWZtHG+TsO PH9IAj66/zyZAJZMBkcp3I0ZcqeKKV96q5yxx42X81SqxzQm3RWUmNuEVX4tOCtb61WmRTZa4P/1 yTnETsVqF0xiUu/fjtBHr2eJeBDDHgrg9YN56/b08DktAKO5x/kIsGo4HzgXLiAVgJY+jkYLJ4vh eG5xuba6hxXvTfyGIHJP27fBCA+tcNcBCnLwu/hD1mg+oZafl7FS0LwsNGjAheCsVXXvBQvobw== --001a113e2436ec88260547804432-- From nobody Wed Feb 1 15:33:06 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AE212952F; Wed, 1 Feb 2017 15:33:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148599198160.18639.10550376619735500869.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 15:33:01 -0800 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:33:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME of the IETF. Title : Internationalized Email Addresses in X.509 certificates Authors : Alexey Melnikov Weihaw Chuang Filename : draft-ietf-lamps-eai-addresses-06.txt Pages : 11 Date : 2017-02-01 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternate Name extension that allows a certificate subject to be associated with an Internationalized Email Address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 23 12:16:53 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0259129A9E; Thu, 23 Feb 2017 12:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-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 4368ryaAmxra; Thu, 23 Feb 2017 12:16:44 -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 BCAF7129A8B; Thu, 23 Feb 2017 12:16:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61A19BE3E; Thu, 23 Feb 2017 20:16: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 tnglWHDyLc9J; Thu, 23 Feb 2017 20:16:41 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3157BE38; Thu, 23 Feb 2017 20:16:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487881001; bh=AjFh+hwxoaGT4Bg9EGW7Oh33/RsFfxfBSchIucXBhRw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YTm9gZZQH12Nack20ayVV3WpLbzMx3y017ljvkHbxSlH+xks1sU43iztItMbpS+GU 1PjvVIUQraJBnmJpslzQpf61HJBlKZSHp7ErrsSn7ZniALRcUgG4hQ/oOyHdL92d4Y YvcxRjTfV44NCNuBirr+vpA/QD4JnVj/woFIKbgM= To: IETF general list References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> Date: Thu, 23 Feb 2017 20:16:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2R6chPAJhdmCeBoGv7Vpuq8RIa5KjpgOq" Archived-At: Cc: "spasm@ietf.org" Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 20:16:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2R6chPAJhdmCeBoGv7Vpuq8RIa5KjpgOq Content-Type: multipart/mixed; boundary="m4Oprf2X5omJppHEuE2lgRu79Csoi6dwu"; protected-headers="v1" From: Stephen Farrell To: IETF general list Cc: "spasm@ietf.org" Message-ID: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> Subject: Re: Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard References: In-Reply-To: --m4Oprf2X5omJppHEuE2lgRu79Csoi6dwu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, I've just reviewed the IETF LC for this draft. Thanks all for the comments and discussion which I think have thrown up some real issues. As of now, it is not clear to me that we have finished the work with this one, at least the issues to do with name constraints seem to me to call for some more WG consideration. I think Russ (as lamps WG chair) has a similar opinion that we're not done yet. That said, I had put this on the March 16th IESG telechat for consideration. If we do manage to reach a clear enough consensus on a published revision to the draft in say the next week then that schedule should still be fine. So I'd encourage the authors and others who've commented to try again and see if, in that timeframe, we can get to where we're happy that the issues raised have been handled well enough. But, if it looks (as it does to me today) as if this'll take a bit longer to figure out, then I figure the right thing to do will be to let the lamps WG figure out how to proceed. (And that'll mean that my successor as the responsible AD for the lamps WG will handle further actions with the doc.) Bottom line: if this isn't settled in the next week or so, I'll take it off the March 16th IESG telechat and let the WG continue the discussion. Cheers, S. PS: To add to the name constraints discussion, I did wonder if anyone really wants to use those. So for example, if we defined the new name form so that certificate chains with any name constraints at all and one of those names anywhere are always treated as invalid, then would that cause any real breakage? (It certainly would cause theoretical breakage, but if that's all then I'd be ok with that:-) --m4Oprf2X5omJppHEuE2lgRu79Csoi6dwu-- --2R6chPAJhdmCeBoGv7Vpuq8RIa5KjpgOq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYr0MoAAoJEC88hzaAX42iSzwH/1yMzfZM6R6n2lSp/CA3UFqx GiYs0O+mEjMu+u/12zZ0j3FZZok+o1YORo9G+oLq4MpdlMQ0TfB7mmXiHILrvwVq 8IcUFb06FVSeMZInALlQV1X+HlRtHNYMUBqBQXkyoirl4zslKndhno/OlYqtHMaG yuUjLO02pcEsF8pFzQZ2V1sBh8fzCvBO9zKOYfKxm+HcpvioEhCUl3WWwlNOTPGG hl7EhKDXcZeH2zOi0iORbdZkSevF1LxUlzvHAx2/2GICxaX9hMFZq07bvp2XutMX uqreRG6GlfVc9Xz9UHwNc5MzHwXyH8sCIAQjC5h3MV/eagThqjL+apBLzVeb5cs= =9iCT -----END PGP SIGNATURE----- --2R6chPAJhdmCeBoGv7Vpuq8RIa5KjpgOq-- From nobody Thu Feb 23 13:46:20 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404E412940A; Thu, 23 Feb 2017 13:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 7LV7Za_VGJTP; Thu, 23 Feb 2017 13:46:17 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172B4129997; Thu, 23 Feb 2017 13:46:16 -0800 (PST) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1487886372; h=from:subject:to:date:message-id; bh=u7Vz5MbN7nAQN6W9gBIiMddB31v9jF7HvbVUsqBS3Qs=; b=WhyWd+EU83geu92MZaKj7LK6q9XxdwqkeW7Eb33PFsKTmYSgVKnsq6e7EzRTdiZ5lEhu9SxPwmM v4haIVQpapKhLfRI791bMHRkgE9lavOWo51GBqVfE88T4onvEQX9GcywVYLeUHpEeU1P5rzkIJm0G lpFbdCzkoJHL7y+WnhHdGGjHTuigLPLIfI8ZBunQgI2u7hgrsgNNkB8en7VrQNTCAH16rJQtVC3+L 86KWamYJb/0I1EF8LCStym0wqCDQNNpHkTIm6PKuTNty2SV7kQEPiOVNPK3xBNKgr+NKGUClB8enL GRrxFERlpCaSfNGIsreEZMfojTJwxyZF5chQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 13:46:11 -0800 Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 13:43:36 -0800 From: Jim Schaad To: 'John C Klensin' , References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 23 Feb 2017 13:44:53 -0800 Message-ID: <009201d28e1e$13337c30$399a7490$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLDY2fkRCgzG0ihtoVsZdX9vIbgygGIv4dMn4kvBMA= X-Originating-IP: [173.8.216.38] Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:46:19 -0000 John, I have used and have seen used the term of US-ASCII to refer to 7-bit ASCII as opposed to the full 8-bit ASCII. I think that this generally makes sense and therefore am unsure that the term should be removed. Jim > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of John C Klensin > Sent: Sunday, January 22, 2017 11:47 AM > To: ietf@ietf.org > Cc: spasm@ietf.org; lamps-chairs@ietf.org; draft-ietf-lamps-eai- > addresses@ietf.org > Subject: Re: [Spasm] Last Call: > (Internationalized Email Addresses in X.509 certificates) to Proposed > Standard > > > > --On Monday, January 16, 2017 2:45 PM -0800 The IESG secretary@ietf.org> wrote: > > > The IESG has received a request from the Limited Additional > >Mechanisms for PKIX and SMIME WG (lamps) to consider the following > >document: - 'Internationalized Email Addresses in > > X.509 certificates' > > as Proposed Standard > >... > > Hi. > > This note is the result of a quick review for email, SMTPUTF8 > and general I18n issues only. I have some questions about > general comprehensibility but, in part because I have not carefully followed > the work that this extends, I'll leave those questions to others and the RFC > Editor. Most of what follows is nit-picking, but significant parts of it may > affect the comprehensibility of the document and hence the ability of > implementers, working it good faith, to conform and create interoperable > implementations. > > (1) The term "EAI" was the hastily-chosen short name/ abbreviation for a > WG. It is not the name of a protocol, system, technique, etc. The relevant > standards-track RFCs are very clear that, if a reference is made to the > relevant SMTP extension and associated protocols, the term should be > "SMTPUTF8". "Internationalized Email Addresses" in the title is ok, but there > should be no IANA registry, subregistry, or module that uses the "EAI" > terminology. > > (2) The base document [RFC5280] is referenced as depending on RFC 5322 > addresses. 822-addresses (used in message headers, > etc.) are not the same as 821-addresses (used in the SMTP envelope). One > can make a case for either, but neither is a proper subset of the other. This is > important in this context because the document then talks about extending > 5280 to accommodate RFC 6531-style addresses. Those are envelope-style > addresses, not message header-style ones. I think the protocol specifics may > be ok due to the language in the third (" This document further refines..." > and subsequent paragraphs in Section 3, but the explanation could easily be > a source of confusion and may need some clarification. > > Note that, as proposals are kicked around that move information from the > mailbox name to the descriptive phrase (which does not exist in envelope > names) during mailing list expansion or some models of post-delivery > SMTPUTF8 "downgrading", any confusion about this issue may become > important (again, the I-D explicitly prohibits the phrase, but only after talking > a lot about 822-style addresses). > > (3) A MUST NOT requirement on the use of A-labels has often been > problematic because, as far as a protocol that does not support IDNA is > concerned, they are ordinary labels conforming to the "preferred syntax" of > RFC 1034/1035 (commonly known as "LDH syntax"). As important, it is easily > possible to construct strings that look (lexically) like A-labels but are actually > not > A-labels. If the desire is to prevent the use of anything but > normal (i.e., not IDNA) LDH labels and U-labels, the restriction that is > probably needed is either "no label starting in 'xn--'" > or "no label starting in two letters followed by two hyphen-minus > characters". Requiring NR-LDH restrictions probably solves the problem > (although I'm not sure what "solely ASCII character labels" means -- see (2) > above) but requires much more specific knowledge of the IDNA2008 protocol > set (particularly RFC 5890 in this case) than I predict readers of this document > will have. See RFC 5890 and 5894 for more discussion on this issue and other > recent correspondence about confusing and contradictory usage of "IDN" > and "IDNA" and the associated risks for additional details and risk > descriptions. > > (4) The second paragraph of Section 4 appears to me to be correct. > However, for reasons related to those discussed above, these are not strictly > "conversion" because the operations may fail (and will fail if the U-labels or > A-labels are not strictly valid). It would probably be useful to be explicit that > one of the effects of this definition is to absolutely prohibit domains that do > not conform to IDNA2008 from appearing in certificates (IMO, that is A Good > Thing). > > (5) It may be worth being explicit that there is no normalization or case- > folding permitted with the local-part. > The current text does say that but it may not be obvious to someone not > thoroughly familiar with other specs. > > (6) I assume the RFC Editor would catch this, but the name of the CCS that is > historically most often used for/on the Internet is "ASCII" not "ascii" or some > other variation. "US-ASCII" is common to but, since there isn't any non-US- > ASCII", a little redundant unless reference is being made to the relevant > media type rather than the CCS. The I-D appears to use "ASCII" and "ascii" > inconsistently. > > (7) In part because of the normalization issue mentioned briefly above, the > Security Considerations section should probably mention not only "visually > similar characters" but "visually identical strings". Note that, at least modulo > the non-decomposing character issue, RFC 5890 does not have that problem > because IDNA requires that all input strings be NFC-conforming. > > (8) Perhaps no one cares, but the notation used in Appendix B for > "\u8001\u5E2B@example.com" does not appear to be referenced or > described anywhere in the document, nor is it consistent with the > recommendations of RFC 5137. > > best, > john > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Feb 23 14:02:55 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964C4129B4F; Thu, 23 Feb 2017 14:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 5levUU8IIrWa; Thu, 23 Feb 2017 14:02:48 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A9E1296D5; Thu, 23 Feb 2017 14:02:48 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ch1TL-000Hcz-NF; Thu, 23 Feb 2017 17:02:47 -0500 Date: Thu, 23 Feb 2017 17:02:41 -0500 From: John C Klensin To: Jim Schaad , ietf@ietf.org Message-ID: <70BCBC4290ABB6783F608C84@PSB> In-Reply-To: <009201d28e1e$13337c30$399a7490$@augustcellars.com> References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <009201d28e1e$13337c30$399a7490$@augustcellars.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:02:51 -0000 --On Thursday, February 23, 2017 13:44 -0800 Jim Schaad wrote: > I have used and have seen used the term of US-ASCII to refer > to 7-bit ASCII as opposed to the full 8-bit ASCII. I think > that this generally makes sense and therefore am unsure that > the term should be removed. Jim, I don't have time to go through this again, but... (1) Depending on what you count, there is either no such thing as "8-bit ASCII" ("full" or otherwise) or it can refer to any of the following: (i) 7-bit ASCII in octets with leading zero bits, as described in RFC 20 and other places. (ii) ISO 8859-1 (aka "Latin-1") (iii) The entire ISO 8850 family, or at least the subset of it that have all or most of ASCII (or at least ISO 646 IRV) in the low-order seven bits So it either doesn't mean what you think it means, or it is hopelessly ambiguous. "US-ASCII" is a different matter. It is a term of art in the IETF, referring to a "charset" that was specified as part of MIME and is now listed in the IANA charset registry. It is essentially equivalent to the first definition above. Unfortunately, "US ASCII" is used in some other contexts to refer to other things, in particular to distinguish between the repertoire of [7 bit) ASCII (i.e., ANSI X3.4) and that of ISO 646 IRV and BV. I personally think the IETF would be better off if we retired the term but YMMD (indeed, I'm probably in the rough), and I'm therefore ok with its use in this context as long as there is a normative reference pointing to a clear definition. My problem is not "remove the term" but being absolutely sure that whatever terminology you use is completely unambiguous. best, john From nobody Thu Feb 23 14:42:35 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C170129BAE; Thu, 23 Feb 2017 14:42:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148788975340.21100.8815642093098663605.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 14:42:33 -0800 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5750-bis-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:42:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5750-bis-02.txt Pages : 25 Date : 2017-02-23 Abstract: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5750-bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 23 14:42:59 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF6D129BD3; Thu, 23 Feb 2017 14:42:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148788977224.21146.5508315086025505343.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 14:42:52 -0800 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:42:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-03.txt Pages : 57 Date : 2017-02-23 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 23 15:22:23 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C807129C10 for ; Thu, 23 Feb 2017 15:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 r9zlJLR8wnwW for ; Thu, 23 Feb 2017 15:22:21 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43106129C0D for ; Thu, 23 Feb 2017 15:22:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1487892138; h=from:subject:to:date:message-id; bh=WufHCLEHg9DOwgl4NEEpnCpV8bZP2T+xdCagq5LLHlI=; b=cItCXA7+aFgVqKR6WPH5eMbJdtiwYpnfzUU1Khu3ePUjZXwfhX783UChGKzO6kv2rZKWMsoTzU1 0KxYisN8afv9bS0/kZ8rOC/sfSVuljFEhWL8YrbVxhDhgr/TxUjN7w8l92ox/7FN9r/uu5zGzMVfE Z/1iAl0nMVO3NvnDMmQbPbaoa8VdriKnuFn8X6X7XBb1FTK2txYC/FqEEA7ItGvv98MDPpahL89r0 1iwmxaW+LAHVHcBN1kyU5O+4L2l3SQ7ge23yXtTS3qo8oN2jbQSBISEtm0oFK+j2TNZZmRHnDfeSc a7weSYWHwPe8yXneKQ/e75TL7xGKLzI3J0YA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 15:22:17 -0800 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 15:20:03 -0800 From: Jim Schaad To: Date: Thu, 23 Feb 2017 15:21:21 -0800 Message-ID: <009c01d28e2b$8c545280$a4fcf780$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKOK3w9gUgcSs1QREeAqQHH8mgLag== X-Originating-IP: [192.168.0.98] Archived-At: Cc: Housley Russ Subject: [Spasm] Ready for Last call X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 23:22:22 -0000 I think that with this push of the two drafts they are ready for last call. Jim From nobody Fri Feb 24 08:47:40 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E39128824 for ; Fri, 24 Feb 2017 08:47:38 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fngxqsOpa3NC for ; Fri, 24 Feb 2017 08:47:36 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 A212C1270B4 for ; Fri, 24 Feb 2017 08:47:33 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id n76so6609866ybg.3 for ; Fri, 24 Feb 2017 08:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=ZamLemaRHxbLY6P0Z6aitVa8pW43wrIPXNEmUSMLQTI=; b=haIepNuxDxCDHWCEL4fqvOe+Vp2odgCfa89UMwOprnGBm6dUzAlaCn//Qsr/Vu+4nn rNM0hXgyzKB0gXBYM/MJTXR6k4/5sm5G2oCpE2plfIFdaSK4JtJKx/mavJl1BRoUE/00 RlVCNCnvK2no0hlrnX/7v4FwVcJ/wXtxmLe73ws6LvKfoCNiBorGSyNiR/TobUSLfX4V sj+Y+4RSEzS6sK1RRRb6W3Y4KuwKEAjCXFNB9UgEp/HMmtwVKMhyUJnZ2ePq0/hZukpQ VGrsqfnX7n/3SUyW5NYijZe/hm3d04iuU3BzuH0Amk8VC95OkoqyxQyZJoF97uuEl3l8 yzwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=ZamLemaRHxbLY6P0Z6aitVa8pW43wrIPXNEmUSMLQTI=; b=sZd+1UOUwR7d0cr/q+fNeBe8Vs9tpa1lX3qqKcMGLSFdRP82T/pWaIJEBDTb/niAuD /ngecUv+woR7bIaFHR39xX1psiveIHz0sYmVrxIjyIbW6cGmVwxZtPTXlGHIVwWBJm98 zuWJuHFLHyvFaHV9k6M06Aikr1dEhrbfOM7fwwSe7BOArrguGvolTatYhEnuShCSXIvI PnoAJIHI9GAkPTZkajBudbMieR/sO3oZ5ihCyyok7B4Te0RanC2xUkJjw2Q86xrryg4s EYfRPU6NvtpFr0/VuhqRsew3V/JsJ/VGZVtj2lLopOgMajzWH1y1s/BNKujTgY5w4YYN 2RGw== X-Gm-Message-State: AMke39nkkIePQ4sHp4kMiTk9X8HIV9vryE6mGjdBj3GeDMGcSxd267yXXafvvmv5qhBAPLLGlTmF7+LslHEEtg== X-Received: by 10.37.181.25 with SMTP id p25mr2356560ybj.56.1487954852637; Fri, 24 Feb 2017 08:47:32 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Fri, 24 Feb 2017 08:47:32 -0800 (PST) From: Phillip Hallam-Baker Date: Fri, 24 Feb 2017 11:47:32 -0500 X-Google-Sender-Auth: Ij0KXBLp2hHBza6RtYxx_3jkf4Q Message-ID: To: SPASM Content-Type: multipart/alternative; boundary=f403045e6ed06ef2660549497c0f Archived-At: Subject: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 16:47:38 -0000 --f403045e6ed06ef2660549497c0f Content-Type: text/plain; charset=UTF-8 All, In the wake of the SHA-1 break, the WebPKI is now down to one digest algorithm. Given the role of the WebPKI, we need two algorithms based on different principles. SHA-3 is the obvious choice. NIST has allocated OIDs but they have parameters and so it is not quite a straight drop in replacement for SHA-2. Deployment of SHA-2 took 15 years, in part because nobody saw the need to deploy SHA-2 until after the Wang attack of 2005. There are many moving parts in this system and one of the major problems is that many parties wait for the others to act before they act. * CABForum can't act until there is an RFC to cite. * HSM vendors won't produce product until there is a demand. There is of course the complicating factor of Curve-X ECC. I note that draft-ietf-curdle-pkix-newcurves is in WG last call. I was previously waiting on that draft passing the IESG to raise Curve-X in CABForum. I suggest the following as an approach for SHA-3/RSA 1) Submit a SHA-3/RSA draft to LAMPS 2) On passing 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm The Curve-X work could happen in parallel and would follow the same approach. I would expect the two would quickly get in sync. --f403045e6ed06ef2660549497c0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All= ,

In the wake of the SHA-= 1 break, the WebPKI is now down to one digest algorithm. Given the role of = the WebPKI, we need two algorithms based on different principles.

SHA-3 is the obvious choice. NIST = has allocated OIDs but they have parameters and so it is not quite a straig= ht drop in replacement for SHA-2.

Deployment of SHA-2 took 15 years, in part because nobody saw th= e need to deploy SHA-2 until after the Wang attack of 2005. There are many = moving parts in this system and one of the major problems is that many part= ies wait for the others to act before they act.

* CABForum can't act until there is an RFC to ci= te.
* HSM vendo= rs won't produce product until there is a demand.

There is of course the complicating factor of = Curve-X ECC. I note that=C2=A0draft-ietf-curdle-pkix-newcurves=C2=A0is in WG last call. I was previously waiting on that draft passing = the IESG to raise Curve-X in CABForum.

I suggest the following as an approach for SHA-3/RSA

1) Submit a SHA-3/RSA draft to LA= MPS
2) On passi= ng=C2=A0
3) Sub= mit a CABForum Ballot to adopt SHA-3 as a approved algorithm

The Curve-X work could happen in parall= el and would follow the same approach. I would expect the two would quickly= get in sync.
<= br>

<= /div> --f403045e6ed06ef2660549497c0f-- From nobody Fri Feb 24 09:48:59 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E953812943F for ; Fri, 24 Feb 2017 09:48:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 70teAkvqQhbF for ; Fri, 24 Feb 2017 09:48:57 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 3F20B129444 for ; Fri, 24 Feb 2017 09:48:57 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id 89so17788485wrr.3 for ; Fri, 24 Feb 2017 09:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=94B/poUhJI5lOqqXibqpdm+01bXKktUorTq/mOpO6dY=; b=tN9WEal7Fg0uwf7r63jUAVjPxkYRXIb0jzYlaE7qyhIS1O4PeYyy4hEKCzXncoXS+o BA/cVYSr9IoXkAobghzTRfaDflAuKUoLrhmRimfwa4EmJwTzUJIFsCGWC+R3pHmb5OjG G82UnjxVBKbvZTLwHxbxy0ruoPTdqS1YP6+P97HeX2M9bveeVKfApNxSfsQq+YxrPCki JsF0jAmfoWrKaw3XBYa8lIw35E2GV7BRDVYySXXYj5jrWiH9qfc0PEffD+F/wRJN9m/L 9Q81Ari1FRqLFKcBkq5S0FJ7qkqf//LngitGRlOmnfNV4rGBaE6KjPZwD7X83cDWFJVt LEtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=94B/poUhJI5lOqqXibqpdm+01bXKktUorTq/mOpO6dY=; b=ZKygqkjf3OYOdzrmesd5CQm9lmhOgDUsM3NDD/f2pD8F2wcUiRGBPjb5v5KQw3RD9r JmKe1GSugsoDXoXn9BYeAqaD0AUUBlKHddD611MqPOIdtj+kl/BAdwBhO/ipqSkF6SAQ WeGrG2vSFaGGf8TNaa3I1ZkMEBUGpA+h4C2MXUqBLSDuiIOsOJ/i5jhVeyxXBuolkYvw j2oN4AN3DlZmWf+uHSubE27y+2EC2Z9DOpH2y6WGE5xloWkD6In1TUR2n2S1t6KEZFJi IeUUnWroCfa3IijCpem3NCiztFpuPiErG7TIuiUMm9yqztpN+2u68RUNhH/UmhatnzPB mfbw== X-Gm-Message-State: AMke39npe8dozxSk8Vz771xTTz2tuQtiRJpJ+LIZvRnxqeNmsBf+53xmUyooRBhfz+NptA== X-Received: by 10.223.147.164 with SMTP id 33mr3796730wrp.108.1487958535748; Fri, 24 Feb 2017 09:48:55 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l45sm1587516wrc.14.2017.02.24.09.48.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 09:48:54 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1CF6FBA5-3FDF-4C4D-ABFF-0DA8C2BF040C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 19:48:51 +0200 In-Reply-To: To: Phillip Hallam-Baker References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:48:59 -0000 --Apple-Mail=_1CF6FBA5-3FDF-4C4D-ABFF-0DA8C2BF040C Content-Type: multipart/alternative; boundary="Apple-Mail=_337ED950-8208-47CA-8CCE-A394B1E9760A" --Apple-Mail=_337ED950-8208-47CA-8CCE-A394B1E9760A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Phil > On 24 Feb 2017, at 18:47, Phillip Hallam-Baker = wrote: >=20 > All, >=20 > In the wake of the SHA-1 break, the WebPKI is now down to one digest = algorithm. Given the role of the WebPKI, we need two algorithms based on = different principles. >=20 > SHA-3 is the obvious choice. NIST has allocated OIDs but they have = parameters and so it is not quite a straight drop in replacement for = SHA-2. >=20 > Deployment of SHA-2 took 15 years, in part because nobody saw the need = to deploy SHA-2 until after the Wang attack of 2005. There are many = moving parts in this system and one of the major problems is that many = parties wait for the others to act before they act. >=20 > * CABForum can't act until there is an RFC to cite. > * HSM vendors won't produce product until there is a demand. >=20 > There is of course the complicating factor of Curve-X ECC. I note that = draft-ietf-curdle-pkix-newcurves = is in WG = last call. I was previously waiting on that draft passing the IESG to = raise Curve-X in CABForum. >=20 > I suggest the following as an approach for SHA-3/RSA >=20 > 1) Submit a SHA-3/RSA draft to LAMPS > 2) On passing > 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm >=20 > The Curve-X work could happen in parallel and would follow the same = approach. I would expect the two would quickly get in sync. Sounds like a plan. Three questions: Why LAMPS rather than CURDLE? What about ECDSA? What is =E2=80=9COn passing=E2=80=9D? --Apple-Mail=_337ED950-8208-47CA-8CCE-A394B1E9760A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Phil

On 24 Feb 2017, at 18:47, = Phillip Hallam-Baker <phill@hallambaker.com> wrote:

All,

In the wake of the = SHA-1 break, the WebPKI is now down to one digest algorithm. Given the = role of the WebPKI, we need two algorithms based on different = principles.

SHA-3 is the obvious = choice. NIST has allocated OIDs but they have parameters and so it is = not quite a straight drop in replacement for SHA-2.

Deployment of SHA-2 took 15 years, in part = because nobody saw the need to deploy SHA-2 until after the Wang attack = of 2005. There are many moving parts in this system and one of the major = problems is that many parties wait for the others to act before they = act.

* = CABForum can't act until there is an RFC to cite.
* HSM vendors won't = produce product until there is a demand.

There is of course the = complicating factor of Curve-X ECC. I note that draft-ietf-curdle-pkix-newcurves is in WG last call. = I was previously waiting on that draft passing the IESG to raise Curve-X = in CABForum.

I suggest the = following as an approach for SHA-3/RSA

1) Submit a SHA-3/RSA = draft to LAMPS
2) On passing 
3) Submit a CABForum = Ballot to adopt SHA-3 as a approved algorithm

The Curve-X work could happen in parallel and = would follow the same approach. I would expect the two would quickly get = in sync.

Sounds = like a plan.  Three questions:
  1. Why LAMPS rather than = CURDLE?
  2. What about ECDSA? 
  3. What= is =E2=80=9COn passing=E2=80=9D?

= --Apple-Mail=_337ED950-8208-47CA-8CCE-A394B1E9760A-- --Apple-Mail=_1CF6FBA5-3FDF-4C4D-ABFF-0DA8C2BF040C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYsHIEAAoJELhJCxUKWMyZ5LAH/27bV/OdOK8yQgtkTww6RG/m tx2aK5SYus0yDQXLVwXfFdOt2QKZ33B+jez/B9b6/gAIHbS/9lTKgJwO69/4twNU rPeDCigLEUPzXPowxJzlS+2XiFWBtdYNEWyxBzyNG5ZjUHiAgWAtLAfGzw7BJm/B qNAu/c8cu0JgaPIxm44zzfJD2P6uNpCJ6TyzdmJqqBeYJGdOKLL9yYcjx1s378ka 4M2mJfBrr1ifV3sr2QbML9nOZ9Bnm0YtWqK0xOXogBdMoKhAS/iE4AUk95r0n6WP hOUlSST8JR1ET/ElmwZ7WfWv4D5WCgV052bAZvAQJH8SyWSklv8dh5pSDZD66GE= =o3ab -----END PGP SIGNATURE----- --Apple-Mail=_1CF6FBA5-3FDF-4C4D-ABFF-0DA8C2BF040C-- From nobody Fri Feb 24 10:23:39 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69234129484 for ; Fri, 24 Feb 2017 10:23:38 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MY6VcBj1uS6q for ; Fri, 24 Feb 2017 10:23:36 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 C7F5112947A for ; Fri, 24 Feb 2017 10:23:36 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id n76so7276641ybg.3 for ; Fri, 24 Feb 2017 10:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9ISCIZZr+eOxBi3PW/6ldLV+miR+mMTVzlPqU2/gS4I=; b=M5lv2B4nkbGIgGap0h9VwEuP38k8j4gUinM98e81yFPLtL69cGdT9Z/snDjlexiU8V uBqvsCxzjH9CRDJsVfLh+32kJrF14+dpRIjCoBWu1HtVkPT+4PpvqInWaFbgZx9F1OHe 1AoFaSdPbANNznDMI+ieqVK1jmhVf4Qex23Umo8SCEHx78pW6ihh+1l3IgSRG/ZOWkL1 rgnT8+EpfevgxoO6cQcMap6T2lIxPS870DhgmVMc/q+yO2UFTs8uDyhSKvvzWC7J4ZLe t2VgfaZIkHXEwCPpV/Ejsg6sKBOqG7ylOCqBQ8WJa06D4C0HWDAqNHddpRR5KxgpIdJm f2bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9ISCIZZr+eOxBi3PW/6ldLV+miR+mMTVzlPqU2/gS4I=; b=b4fwBBTPwfl6wlqR4aIs0vs6nzGVSKoQN0coKvRV4mLz/nCLaV3rsD4a2DRKP2jYU0 ka9lvg36u69TfGbqJj1TSV/EFwseBitnNlFa3sVxiib5NncuAy6PQKVPvStEBojNbDyL 9pI8ZOaTLpScJZeQhD9DQvbwrLfpO3keKbZUcDCl9HbzG9oiC2BECxxsG3Q/de3eePAQ Yeu4ku5i5wu7cXpiEkH8mmKpXEiOoUzfFiyR3Ru06uO7NpkjrVkrapRI0/jVKAA83tkB StclOpTwt3p0UfbbAAn3aDeShlL7x67ugILgsgu5jzLhIoj0Ch524uf7BsAK7EKvm0tp TxOw== X-Gm-Message-State: AMke39km3QztsWGxYySrwjhW86qtZyPXfBewMqYz9eV3vzaDLcnj4pIC4UZISaCv0rP6G8TTmVXTCPoGzHIDpQ== X-Received: by 10.37.217.23 with SMTP id q23mr323711ybg.23.1487960615981; Fri, 24 Feb 2017 10:23:35 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Fri, 24 Feb 2017 10:23:35 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Fri, 24 Feb 2017 13:23:35 -0500 X-Google-Sender-Auth: O4Ilgs56mkNH9Pau7QZYR7-iv-s Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c06ca38f4a02d05494ad36f Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 18:23:38 -0000 --94eb2c06ca38f4a02d05494ad36f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2017 at 12:48 PM, Yoav Nir wrote: > Hi, Phil > > On 24 Feb 2017, at 18:47, Phillip Hallam-Baker > wrote: > > All, > > In the wake of the SHA-1 break, the WebPKI is now down to one digest > algorithm. Given the role of the WebPKI, we need two algorithms based on > different principles. > > SHA-3 is the obvious choice. NIST has allocated OIDs but they have > parameters and so it is not quite a straight drop in replacement for SHA-= 2. > > Deployment of SHA-2 took 15 years, in part because nobody saw the need to > deploy SHA-2 until after the Wang attack of 2005. There are many moving > parts in this system and one of the major problems is that many parties > wait for the others to act before they act. > > * CABForum can't act until there is an RFC to cite. > * HSM vendors won't produce product until there is a demand. > > There is of course the complicating factor of Curve-X ECC. I note that > draft-ietf-curdle-pkix-newcurves > is in WG > last call. I was previously waiting on that draft passing the IESG to rai= se > Curve-X in CABForum. > > I suggest the following as an approach for SHA-3/RSA > > 1) Submit a SHA-3/RSA draft to LAMPS > 2) On passing > 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm > > The Curve-X work could happen in parallel and would follow the same > approach. I would expect the two would quickly get in sync. > > > Sounds like a plan. Three questions: > > 1. Why LAMPS rather than CURDLE? > 2. What about ECDSA? > 3. What is =E2=80=9COn passing=E2=80=9D? > > =E2=80=8B1. Well because the responsible SECAD suggested LAMPS. =E2=80=8B =E2=80=8BIts the same people and could well end up being the same meeting s= lot at some point. I suspect it means he wants CURDLE to do its work and disappear.=E2=80=8B =E2=80=8B2. Good question and was the reason I had been holding off on SHA-= 3. I want both of course. But Curve-X requires a bit more prep than SHA-3. 3. CABForum does not need to wait for an RFC to be passed to begin discussions but it will probably need to have an RFC available to vote on a motion. So I would look to raise this in CABForum as soon as it passed the IESG and propose the ballot as soon as the RFC passed.=E2=80=8B =E2=80=8B=E2=80=8B --94eb2c06ca38f4a02d05494ad36f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Fe= b 24, 2017 at 12:48 PM, Yoav Nir <ynir.ietf@gmail.com> wro= te:
H= i, Phil

= On 24 Feb 2017, at 18:47, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
All,

In the wake of the SHA-1 b= reak, the WebPKI is now down to one digest algorithm. Given the role of the= WebPKI, we need two algorithms based on different principles.

SHA-3 is t= he obvious choice. NIST has allocated OIDs but they have parameters and so = it is not quite a straight drop in replacement for SHA-2.

Deployment of= SHA-2 took 15 years, in part because nobody saw the need to deploy SHA-2 u= ntil after the Wang attack of 2005. There are many moving parts in this sys= tem and one of the major problems is that many parties wait for the others = to act before they act.

* CABForum can't act until there is an RFC to= cite.
* HSM vendors won't produce = product until there is a demand.

There is of course the complicating fact= or of Curve-X ECC. I note that=C2=A0draft= -ietf-curdle-pkix-newcurves=C2=A0is in WG last call. I was previou= sly waiting on that draft passing the IESG to raise Curve-X in CABForum.

= I suggest the following as an approach for SHA-3/RSA

1) Submit a SHA-3/RS= A draft to LAMPS
2) On passing=C2=A0
3) Submit a CABForum Ballot to adopt SHA-= 3 as a approved algorithm

The Curve-X work could happen in parallel and w= ould follow the same approach. I would expect the two would quickly get in = sync.

Sounds like = a plan.=C2=A0 Three questions:
  1. Why LAMPS rather than CURDLE?
  2. What about ECDSA?= =C2=A0
  3. What is =E2=80=9COn passing=E2=80=9D?
<= /div>
=E2=80=8B1. Well because the responsible SECAD suggested LAMPS. =E2=80= =8B

=E2=80=8BIts the same people and could well end up being the same meeti= ng slot at some point. I suspect it means he wants CURDLE to do its work an= d disappear.=E2=80=8B

=E2=80=8B2. Good question and was the reason I had be= en holding off on SHA-3.=C2=A0

I want both of course. But Curve-X requires a bit more prep than SHA-= 3.

3. CABForum does not n= eed to wait for an RFC to be passed to begin discussions but it will probab= ly need to have an RFC available to vote on a motion. So I would look to ra= ise this in CABForum as soon as it passed the IESG and propose the ballot a= s soon as the RFC passed.=E2=80=8B


=E2=80=8B=E2=80=8B
<= br>
--94eb2c06ca38f4a02d05494ad36f-- From nobody Fri Feb 24 11:57:40 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325E0129500 for ; Fri, 24 Feb 2017 11:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fYuylqtxjVh for ; Fri, 24 Feb 2017 11:57:34 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1551294F8 for ; Fri, 24 Feb 2017 11:57:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CDBE030042F for ; Fri, 24 Feb 2017 14:57:33 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JN5gdAbvM72H for ; Fri, 24 Feb 2017 14:57:33 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id EA46A30024F; Fri, 24 Feb 2017 14:57:32 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <009c01d28e2b$8c545280$a4fcf780$@augustcellars.com> Date: Fri, 24 Feb 2017 14:57:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5BB5A990-131C-469F-988C-533B0E93B604@vigilsec.com> References: <009c01d28e2b$8c545280$a4fcf780$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3259) Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Ready for Last call X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 19:57:39 -0000 I=E2=80=99m making a quick scan of the diff. If nothing jumps at me, = then I=E2=80=99ll issue the WG Last Call. Russ > On Feb 23, 2017, at 6:21 PM, Jim Schaad = wrote: >=20 > I think that with this push of the two drafts they are ready for last = call. >=20 > Jim From nobody Fri Feb 24 12:26:52 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90291129502 for ; Fri, 24 Feb 2017 12:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fV2Ca8zuhXeY for ; Fri, 24 Feb 2017 12:26:50 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F451294FB for ; Fri, 24 Feb 2017 12:26:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 214CF30042E for ; Fri, 24 Feb 2017 15:26:50 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zteq9KwE3v0H for ; Fri, 24 Feb 2017 15:26:49 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 648C730024D for ; Fri, 24 Feb 2017 15:26:49 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Fri, 24 Feb 2017 15:26:49 -0500 To: SPASM X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:26:51 -0000 This is the LAMPS WG Last Call for "Secure/Multipurpose Internet Mail = Extensions (S/MIME) Version 4.0 Certificate Handling=E2=80=9D = . Please review the document and send = your comments to the list by 10 March 2017.=20 Thanks, Russ= From nobody Fri Feb 24 12:28:09 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4DC1294FC for ; Fri, 24 Feb 2017 12:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3Mln6hv_msu for ; Fri, 24 Feb 2017 12:28:07 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8793B1294FB for ; Fri, 24 Feb 2017 12:28:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 00AB430042E for ; Fri, 24 Feb 2017 15:28:06 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id c1cc1j3uecLF for ; Fri, 24 Feb 2017 15:28:06 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 623C930024D for ; Fri, 24 Feb 2017 15:28:06 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <2AFA0160-B45D-456E-A642-41863274A7EE@vigilsec.com> Date: Fri, 24 Feb 2017 15:28:06 -0500 To: SPASM X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:28:08 -0000 This is the LAMPS WG Last Call for "Secure/Multipurpose Internet Mail = Extensions (S/MIME) Version 4.0 Message Specification=E2=80=9D = . Please review the document and send = your comments to the list by 10 March 2017.=20 Thanks, Russ From nobody Fri Feb 24 12:40:12 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9701294FD for ; Fri, 24 Feb 2017 12:40:11 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 0iz_l3fhM_dG for ; Fri, 24 Feb 2017 12:40:09 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 A0D3A1294FB for ; Fri, 24 Feb 2017 12:40:08 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id o22so14813029wro.1 for ; Fri, 24 Feb 2017 12:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GvmYKu2PK+acrm1kdMl+3nCi0VIMMVXuQmNjLOEQFW4=; b=VNi1oXdbBPNcDIfTxG9d8L3QldiPB0nyLABx+P+We2C1IDVOgE4tyatTKrTE/+Drxp Vqr+3tsHIn695VIg3XSX/zD/SeRh5aWpTEUx1SLn4uDo3CktOzwyfXfL63Ph9Ob826n3 nItTA4fVcqIKkouNXQu8SV1WdBYpFAMH+eCyeOdmsIn3rSSDkdjE5L8mUq2QDyXIySJN rwPAK3Wv+S8X49IqTJ6z9MilW+fh8+IFbHiyJPL4Ix9xmi3Mi18lVMWBVOeNp92WG51i R0cKFQt6JNFh6bdpOCgqwH3BRrk8u+EtZKc5vei8VCbc75GAH5dlWkaUgNaSQWRvfo29 c0bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GvmYKu2PK+acrm1kdMl+3nCi0VIMMVXuQmNjLOEQFW4=; b=cGZNhu6R5fK8znVz3Q/thTm1RVasUq7avLiuvSeUekFRO3bQV1i9Mu/aOAnozgkGcr O3EM8wz4uJ37nObR79aapA0JFj0giuJV94EOnHlvENuA+RelJUv+tOCewlbsGt4MmQoe gb5zKABCtG4I6SUMPoVgv7sMhYfgl4goso8SjTvvuEfDDo3LJ98+uzMk39woJI/XkgK/ 5SAYEfriQqbWq7wRjCwVMAnLuyTZniQ/E7/LVq4iCLBUkG5wQztiJS4qZriyKeOYeY8f o9vDR3a9gx4QoFInfmg5DTbjJsbHd7a8yxcNk/eb0YTkuhF3fnIos4TQehbLcWE0mMcW xB0g== X-Gm-Message-State: AMke39lc67tCABS4tS3pFvp+Wxq01ooZO/rnDsS5mrvi2cXo5SLFIAsEJgoIb9/WJQ50xg== X-Received: by 10.223.165.17 with SMTP id i17mr4738365wrb.62.1487968807071; Fri, 24 Feb 2017 12:40:07 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g5sm11679286wrd.0.2017.02.24.12.40.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 12:40:06 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_767196E2-314E-46ED-891D-01CC949E2C0E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 22:40:03 +0200 In-Reply-To: To: Phillip Hallam-Baker References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:40:11 -0000 --Apple-Mail=_767196E2-314E-46ED-891D-01CC949E2C0E Content-Type: multipart/alternative; boundary="Apple-Mail=_CD5002E9-BF1D-4A8F-BD74-98C5573B575E" --Apple-Mail=_CD5002E9-BF1D-4A8F-BD74-98C5573B575E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Feb 2017, at 20:23, Phillip Hallam-Baker = wrote: >=20 >=20 >=20 > On Fri, Feb 24, 2017 at 12:48 PM, Yoav Nir > wrote: > Hi, Phil >=20 >> On 24 Feb 2017, at 18:47, Phillip Hallam-Baker > wrote: >>=20 >> All, >>=20 >> In the wake of the SHA-1 break, the WebPKI is now down to one digest = algorithm. Given the role of the WebPKI, we need two algorithms based on = different principles. >>=20 >> SHA-3 is the obvious choice. NIST has allocated OIDs but they have = parameters and so it is not quite a straight drop in replacement for = SHA-2. >>=20 >> Deployment of SHA-2 took 15 years, in part because nobody saw the = need to deploy SHA-2 until after the Wang attack of 2005. There are many = moving parts in this system and one of the major problems is that many = parties wait for the others to act before they act. >>=20 >> * CABForum can't act until there is an RFC to cite. >> * HSM vendors won't produce product until there is a demand. >>=20 >> There is of course the complicating factor of Curve-X ECC. I note = that draft-ietf-curdle-pkix-newcurves = is in WG = last call. I was previously waiting on that draft passing the IESG to = raise Curve-X in CABForum. >>=20 >> I suggest the following as an approach for SHA-3/RSA >>=20 >> 1) Submit a SHA-3/RSA draft to LAMPS >> 2) On passing >> 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm >>=20 >> The Curve-X work could happen in parallel and would follow the same = approach. I would expect the two would quickly get in sync. >=20 > Sounds like a plan. Three questions: > Why LAMPS rather than CURDLE? > What about ECDSA? > What is =E2=80=9COn passing=E2=80=9D? > =E2=80=8B1. Well because the responsible SECAD suggested LAMPS. =E2=80=8B= >=20 > =E2=80=8BIts the same people and could well end up being the same = meeting slot at some point. I suspect it means he wants CURDLE to do its = work and disappear.=E2=80=8B OK > =E2=80=8B2. Good question and was the reason I had been holding off on = SHA-3. >=20 > I want both of course. But Curve-X requires a bit more prep than = SHA-3. The two EdDSA curves I understand. But what about ECDSA with the NIST = curves? Currently each of the three curves (P-256, P-384, and P-521) is = used with one of the SHA2 variants. Don=E2=80=99t you want them with = SHA3 variants? > 3. CABForum does not need to wait for an RFC to be passed to begin = discussions but it will probably need to have an RFC available to vote = on a motion. So I would look to raise this in CABForum as soon as it = passed the IESG and propose the ballot as soon as the RFC passed.=E2=80=8B= OK --Apple-Mail=_CD5002E9-BF1D-4A8F-BD74-98C5573B575E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 24 Feb 2017, at 20:23, Phillip Hallam-Baker <phill@hallambaker.com> wrote:



On Fri, Feb 24, 2017 at 12:48 PM, Yoav Nir <ynir.ietf@gmail.com> = wrote:
Hi, Phil

On 24 Feb 2017, at 18:47, = Phillip Hallam-Baker <phill@hallambaker.com> = wrote:

All,

In the wake = of the SHA-1 break, the WebPKI is now down to one digest algorithm. = Given the role of the WebPKI, we need two algorithms based on different = principles.

SHA-3 is the = obvious choice. NIST has allocated OIDs but they have parameters and so = it is not quite a straight drop in replacement for SHA-2.

Deployment of SHA-2 took 15 years, = in part because nobody saw the need to deploy SHA-2 until after the Wang = attack of 2005. There are many moving parts in this system and one of = the major problems is that many parties wait for the others to act = before they act.

* CABForum = can't act until there is an RFC to cite.
* HSM vendors won't produce product = until there is a demand.

There is of course the complicating factor of Curve-X ECC. I = note that draft-ietf-curdle-pkix-newcurves is in WG last call. I was previously = waiting on that draft passing the IESG to raise Curve-X in = CABForum.

I suggest the = following as an approach for SHA-3/RSA

1) Submit a SHA-3/RSA draft to LAMPS
2) On passing 
3) Submit a CABForum Ballot to = adopt SHA-3 as a approved algorithm

The Curve-X work could happen in parallel and would follow = the same approach. I would expect the two would quickly get in = sync.

Sounds like a plan.  Three questions:
  1. Why LAMPS rather than CURDLE?
  2. What about = ECDSA? 
  3. What is =E2=80=9COn = passing=E2=80=9D?
=E2=80=8B= 1. Well because the responsible SECAD suggested LAMPS. =E2=80=8B

=E2=80=8BIts the same people and could well = end up being the same meeting slot at some point. I suspect it means he = wants CURDLE to do its work and = disappear.=E2=80=8B
<= br class=3D"">
OK

=E2=80=8B2. Good = question and was the reason I had been holding off on = SHA-3. 

I want both of course. = But Curve-X requires a bit more prep than = SHA-3.

The two EdDSA curves I understand. But what about = ECDSA with the NIST curves? Currently each of the three curves (P-256, = P-384, and P-521) is used with one of the SHA2 variants. Don=E2=80=99t = you want them with SHA3 variants?

3. CABForum does not = need to wait for an RFC to be passed to begin discussions but it will = probably need to have an RFC available to vote on a motion. So I would = look to raise this in CABForum as soon as it passed the IESG and propose = the ballot as soon as the RFC passed.=E2=80=8B

OK

= --Apple-Mail=_CD5002E9-BF1D-4A8F-BD74-98C5573B575E-- --Apple-Mail=_767196E2-314E-46ED-891D-01CC949E2C0E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYsJokAAoJELhJCxUKWMyZwF8H/RCEt2EQaK4X52KVOrf+DELe s8Grv1ZuERgUT+UyCgps9j7lU77eon10S8Sc5zh1kKsdG4EnURxgopsKziQl9FpM cSx7zwLKnaJC91gRzyLCCeZFl9qK17FTJ4nksLOML/gG1FD1BBZyRLyJgLwEBeaB qPZwpT7fElsGSnIbczLK7gIkgk4GGvyc4Hx3q0vpyFbWn95tiQ1NGQtTb5mMia+u SszctBuB6GV6lv1hKC/pxa7f+6cNQ+wDCnRFbQ7fcbTP0gylbZgzYvpB7sNXaxJl AlD2HVTFISDLVMaMfhX3vxsHQ5ON+qmxnMcuIo/d7lKZYXhg4vyCMZPbOvzTI+k= =nauB -----END PGP SIGNATURE----- --Apple-Mail=_767196E2-314E-46ED-891D-01CC949E2C0E-- From nobody Fri Feb 24 12:53:35 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF161294FB for ; Fri, 24 Feb 2017 12:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 C3lVfjf-xkhU for ; Fri, 24 Feb 2017 12:53:33 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 6B6A4129507 for ; Fri, 24 Feb 2017 12:53:33 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id v200so15233038ywc.3 for ; Fri, 24 Feb 2017 12:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6vO6QgEr7EFU1Pz9xUOOSLlJBGQPMzXV+AXgm3PRjrg=; b=LLuT+/6+5xGU8QPS3dHQE6yAzWuNz4O3mv1T72QXhmreeGdThNavEx3B0bFabJEq5c GHsl61XO5CZTgU44/ntemOCj9hHtUS9MKB0ctukllcQ0OkORLKFRb6myo4LxIgcqPxoR JFvnaRkrNXbCkB7aB3K0ilg0omygRwfpK44g+rFPSaxWT7G9T16RgrgQNrstPCfobIVw cfpDnq8Q5trGs7p5FtZsL9/RE8XqSVjQO3+m86LJ/8Xs0Gr95DtTwQ3o66e4tcFCt00x rfUMUA6Ad8yxzQzvekCWh3COiY9AIIxlcYMCPCYLIp6piOVWOsYu7mZctzaj74FhksgI xnvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6vO6QgEr7EFU1Pz9xUOOSLlJBGQPMzXV+AXgm3PRjrg=; b=jhLi1KGhPRYwgNvBlkz4TeYaHruUGfoIvZU6zNIhHhnZk3CAfWOR/wn+Zheg1QZUEO wYmji0p+vO8KRp1BG2525KDZbo/nOi+SlLpxv4pgqPIHA6cinFRZ5ta1cYz8UE3w5lqq iT82v1OyzwGzBliOum/XIYH2oY+Dt4k1WDL5dqjGe87usrZ6zsO8cUcdbUGDDHF06wuU h3H6Dhfv4o5I++60XKDGKBj0xrAg1QPC1n38jWZCG8n/RNBGN/y4YuhoJpdzTw6d9XUZ SPERGXfMXDSplJKMWb/nXxBGznGpuHVRK+BMBCPnAblr8ov/CpiFGB+FQp8l8M/sd27c 6RcA== X-Gm-Message-State: AMke39kPJRXE2X59nDlryokbbWUB0pGvruf22t/EW66f605gfX9An8tDgOst4Kx3JhdDnKZPOsVPgsIzwAb8/g== X-Received: by 10.129.109.75 with SMTP id i72mr3039462ywc.340.1487969612664; Fri, 24 Feb 2017 12:53:32 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Fri, 24 Feb 2017 12:53:32 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Fri, 24 Feb 2017 15:53:32 -0500 X-Google-Sender-Auth: j9YzOLwNLFnjQylJNwl1X4Zzjao Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a114db4ac3335a605494cec29 Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:53:34 -0000 --001a114db4ac3335a605494cec29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir wrote: > =E2=80=8B2. Good question and was the reason I had been holding off on SH= A-3. > > I want both of course. But Curve-X requires a bit more prep than SHA-3. > > > The two EdDSA curves I understand. But what about ECDSA with the NIST > curves? Currently each of the three curves (P-256, P-384, and P-521) is > used with one of the SHA2 variants. Don=E2=80=99t you want them with SHA3= variants? > =E2=80=8BNo.=E2=80=8B =E2=80=8BNIST EdDSA withj SHA-2 is in the CABForum list of approved algorit= hms. But I can't see there being momentum behind uses of those curves in the future. I think we have made a decision to focus on Curve-X I don't see any need to remove them. Particularly when the curve that is used most is P-384 which is rather stronger than 25519. But Curve-X is our chosen path and we should not re-litigate that. =E2=80=8BThere are a large number of algorithms that I would like to see pu= rged. =E2=80=8BIn fact pretty much everything that isn't AES, RSA, SHA-2, SHA-3, = Curve-X, Cha-Cha20 or close relatives (Blake2, HMAC). =E2=80=8BWe don't actually add security by adding new algorithms. We only a= dd security byu removing the weak ones. Anything that is not widely used and necessary is just more attack surface.=E2=80=8B --001a114db4ac3335a605494cec29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
= =E2=80=8B2. Good question and was the reason I had been holding off on SHA-= 3.=C2=A0

I want both of course. But Curve-X requires a bit more prep than= SHA-3.

The two EdDSA curves I understand. But what about ECDSA with the NI= ST curves? Currently each of the three curves (P-256, P-384, and P-521) is = used with one of the SHA2 variants. Don=E2=80=99t you want them with SHA3 v= ariants?

=E2=80=8BNo.=E2=80=8B

=E2=80=8BNIST = EdDSA withj SHA-2 is in the CABForum list of approved algorithms. But I can= 't see there being momentum behind uses of those curves in the future. = I think we have made a decision to focus on Curve-X

I don't see any need to remove them. Particu= larly when the curve that is used most is P-384 which is rather stronger th= an 25519. But Curve-X is our chosen path and we should not re-litigate that= .


=E2=80=8BThere are a large number of algorithms that I wou= ld like to see purged. =E2=80=8BIn fact pretty much everything that isn'= ;t AES, RSA, SHA-2, SHA-3, Curve-X, Cha-Cha20 or close relatives (Blake2, H= MAC).

=E2=80=8BWe don'= ;t actually add security by adding new algorithms. We only add security byu= removing the weak ones. Anything that is not widely used and necessary is = just more attack surface.=E2=80=8B

--001a114db4ac3335a605494cec29-- From nobody Fri Feb 24 13:00:14 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BAE1294FB for ; Fri, 24 Feb 2017 13:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=augustcellars.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 1-GMassBm4vF for ; Fri, 24 Feb 2017 13:00:10 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33F61294F8 for ; Fri, 24 Feb 2017 13:00:10 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01D28E9D.EA6457E0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1487970004; h=from:subject:to:date:message-id; bh=thZ5LvQmzd7p5HHU5eSbZO3vtbnFDh69aKXYTSE8wck=; b=YJvk0bi6iBF/lFOx8tnYUoX3ZqrFZ4kHNLhtbL2J3FTeCU2n3l3mLRIgiO5dembGZo7okle5Sho bz2EdZshCUzqVleCAAxnRkbMm0bziyG+6horyO0SY6vPpCCxjGxILbzYIRpuc5ZZeMMqoFovQEvrT bDwfw9adjW2Ddr2HvUaYyGPC3zMWh6323xP/HKAVhh/PVh7lB2KuAocn5es7LJdvq4XwNSZWo5jPT UV9By1Oo9jahawshNfN299yq4eLx+FH52e4eCXbP5EucI466Nz4oOfXKYUy8AeRwODZhMaDvP5fbq Px+5zMnH9K0ST61OxWOfXhEi7yjq8JEILvsg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 24 Feb 2017 13:00:04 -0800 Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 24 Feb 2017 12:57:52 -0800 From: Jim Schaad To: 'Phillip Hallam-Baker' , 'Yoav Nir' References: In-Reply-To: Date: Fri, 24 Feb 2017 13:00:00 -0800 Message-ID: <001301d28ee0$f88526e0$e98f74a0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH/DeePlMOzfMLiPF+DJ1lfrkmRzgKCCylnAq7MJuYCpKUkVAFwUxCGoNV3XpA= X-Originating-IP: [173.8.216.38] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 21:00:12 -0000 ------=_NextPart_000_0014_01D28E9D.EA6457E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker Sent: Friday, February 24, 2017 12:54 PM To: Yoav Nir Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX =20 On Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir > wrote: =E2=80=8B2. Good question and was the reason I had been holding off on = SHA-3.=20 =20 I want both of course. But Curve-X requires a bit more prep than SHA-3. =20 The two EdDSA curves I understand. But what about ECDSA with the NIST = curves? Currently each of the three curves (P-256, P-384, and P-521) is = used with one of the SHA2 variants. Don=E2=80=99t you want them with = SHA3 variants? =20 =E2=80=8BNo.=E2=80=8B =20 =E2=80=8BNIST EdDSA withj SHA-2 is in the CABForum list of approved = algorithms. But I can't see there being momentum behind uses of those = curves in the future. I think we have made a decision to focus on = Curve-X =20 [JLS] I am having a bit of a problem with this. EdDSA w/ 25519 uses = SHA-2, but w/448 uses SHA-3. The blanket statement of Curve-X uses = SHA-2 is not correc.t =20 Jim =20 =20 I don't see any need to remove them. Particularly when the curve that is = used most is P-384 which is rather stronger than 25519. But Curve-X is = our chosen path and we should not re-litigate that. =20 =20 =E2=80=8BThere are a large number of algorithms that I would like to see = purged. =E2=80=8BIn fact pretty much everything that isn't AES, RSA, = SHA-2, SHA-3, Curve-X, Cha-Cha20 or close relatives (Blake2, HMAC). =20 =E2=80=8BWe don't actually add security by adding new algorithms. We = only add security byu removing the weak ones. Anything that is not = widely used and necessary is just more attack surface.=E2=80=8B =20 ------=_NextPart_000_0014_01D28E9D.EA6457E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker
Sent: Friday, February 24, 2017 12:54 = PM
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: = SPASM <SPASM@ietf.org>
Subject: Re: [Spasm] Add SHA-3 to = PKIX

 

On = Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir <ynir.ietf@gmail.com> = wrote:

<= div>

=E2=80=8B2. Good question and was the reason I = had been holding off on SHA-3. 

 

I = want both of course. But Curve-X requires a bit more prep than = SHA-3.

 

The two EdDSA curves I understand. But what about = ECDSA with the NIST curves? Currently each of the three curves (P-256, = P-384, and P-521) is used with one of the SHA2 variants. Don=E2=80=99t = you want them with SHA3 = variants?

 

=E2=80=8BNo.=E2=80=8B

 

=E2=80=8BNIST EdDSA withj SHA-2 is in the CABForum = list of approved algorithms. But I can't see there being momentum behind = uses of those curves in the future. I think we have made a decision to = focus on Curve-X

 

[JLS] I am = having a bit of a problem with this.=C2=A0 EdDSA w/ 25519 uses SHA-2, = but w/448 uses SHA-3.=C2=A0 The blanket statement of Curve-X uses SHA-2 = is not correc.t

 

Jim

 

 

I = don't see any need to remove them. Particularly when the curve that is = used most is P-384 which is rather stronger than 25519. But Curve-X is = our chosen path and we should not re-litigate = that.

 

 

=E2=80=8BThere are a large number of algorithms that I = would like to see purged. =E2=80=8BIn fact pretty much everything that = isn't AES, RSA, SHA-2, SHA-3, Curve-X, Cha-Cha20 or close relatives = (Blake2, HMAC).

 

=E2=80=8BWe don't actually add security by adding new = algorithms. We only add security byu removing the weak ones. Anything = that is not widely used and necessary is just more attack = surface.=E2=80=8B

 

------=_NextPart_000_0014_01D28E9D.EA6457E0-- From nobody Fri Feb 24 13:04:40 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75190129511 for ; Fri, 24 Feb 2017 13:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dpf6ttp8idNk for ; Fri, 24 Feb 2017 13:04:38 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 E1CE612950E for ; Fri, 24 Feb 2017 13:04:37 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id v77so23511710wmv.0 for ; Fri, 24 Feb 2017 13:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=It0pcmHmPlhTzx4n1laSUD+H7FBq1bU8035bonpura0=; b=Qi0rcFYhVod9nj5E3KQXEZ78nHyf0NujGQGnqShcoLHz2UO0O9RDg3xRlWcor58pJ+ e+9dnW6BX4CzQ3cnA+FPIRgsumuDnOp6gh56PytqMGtNs8Cwn1Ki1Sks7UDelPAITcsP 6kv5cISYA+JHEsRI/OphfVb4rQpnJ5s54KO6cc5N0oDKfGEXfwJu2rcs8ZvIXlqhiIpW OvpqLfVKWrLY45NcBvoFyLmAasxICy4jBYoTw6PUfkdgwCubApYfPphBwtiPJNrscHbc Dfla4Cvqbr7erciZr6zocL1du46p0bVLMPMTILw0NLWyGjF8tnoi02tBZlW1/49o0KXC hu0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=It0pcmHmPlhTzx4n1laSUD+H7FBq1bU8035bonpura0=; b=mEJpO6Z/rmFkqLTvggzm/JFkbJ+simlT9PBmz7bw0mf+N1jRg9GYcIjDUZPQDYWSs5 LRopv566dZOOZaTbFBPwB20zQzvH02iP6W7BENR+8JaFEIKJY7nnz3KgjPEdzocAS6yE 52ihVcDepWz+DgqwqIOgqk+eklQrIx9aF68b8WlB4tbkn+u+AtxxLIJJ9wPq32ohhAvJ Pgnj6QxjpcQuCfZEl03Q+o5OJzPo6eDCOviy2EI9nMbNBvO3gFkMceyOMQqANArSEnHo qryJuPkKbHEHS5T1NyEoTyWjIUycFkTNn2eyP00xp/L1Clu3/zkNiGBaDV9S8xXt4Y// qtuA== X-Gm-Message-State: AMke39kRlt0f4PdpQbwbRmIcuUywOMusG3yCZQZoTjFOltcqyQxDpJCFB239orGBUW5Utg== X-Received: by 10.28.155.9 with SMTP id d9mr4130662wme.114.1487970276383; Fri, 24 Feb 2017 13:04:36 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 32sm11688506wre.15.2017.02.24.13.04.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 13:04:35 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C948799E-0AF7-4661-A9C2-975A27AED817"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 23:04:32 +0200 In-Reply-To: <001301d28ee0$f88526e0$e98f74a0$@augustcellars.com> To: Jim Schaad References: <001301d28ee0$f88526e0$e98f74a0$@augustcellars.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM , Phillip Hallam-Baker Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 21:04:39 -0000 --Apple-Mail=_C948799E-0AF7-4661-A9C2-975A27AED817 Content-Type: multipart/alternative; boundary="Apple-Mail=_9232D628-6F36-4C2A-B6D5-D94F42AD53E0" --Apple-Mail=_9232D628-6F36-4C2A-B6D5-D94F42AD53E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Feb 2017, at 23:00, Jim Schaad wrote: >=20 >=20 >=20 > From: Spasm [mailto:spasm-bounces@ietf.org = ] On Behalf Of Phillip Hallam-Baker > Sent: Friday, February 24, 2017 12:54 PM > To: Yoav Nir > > Cc: SPASM > > Subject: Re: [Spasm] Add SHA-3 to PKIX >=20 > On Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir > wrote: >>> =E2=80=8B2. Good question and was the reason I had been holding off = on SHA-3. >>>=20 >>> I want both of course. But Curve-X requires a bit more prep than = SHA-3. >>=20 >> The two EdDSA curves I understand. But what about ECDSA with the NIST = curves? Currently each of the three curves (P-256, P-384, and P-521) is = used with one of the SHA2 variants. Don=E2=80=99t you want them with = SHA3 variants? >=20 > =E2=80=8BNo.=E2=80=8B >=20 > =E2=80=8BNIST EdDSA withj SHA-2 is in the CABForum list of approved = algorithms. But I can't see there being momentum behind uses of those = curves in the future. I think we have made a decision to focus on = Curve-X >=20 > [JLS] I am having a bit of a problem with this. EdDSA w/ 25519 uses = SHA-2, but w/448 uses SHA-3. The blanket statement of Curve-X uses = SHA-2 is not correc.t >=20 > Jim And EdDSA is not NIST-approved (nor either of the curves). I think Phil = meant ECDSA there. Yoav --Apple-Mail=_9232D628-6F36-4C2A-B6D5-D94F42AD53E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 24 Feb 2017, at 23:00, Jim Schaad <ietf@augustcellars.com> wrote:

 
 
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf = Of Phillip = Hallam-Baker
Sent: Friday, February 24, 2017 = 12:54 PM
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: SPASM <SPASM@ietf.org>
Subject: Re: [Spasm] Add SHA-3 to = PKIX
 
On Fri, Feb 24, 2017 = at 3:40 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
=E2=80=8B2. Good = question and was the reason I had been holding off on SHA-3. 
 
I want both of course. But Curve-X = requires a bit more prep than SHA-3.
 
The two EdDSA curves I understand. But what about = ECDSA with the NIST curves? Currently each of the three curves (P-256, = P-384, and P-521) is used with one of the SHA2 variants. Don=E2=80=99t = you want them with SHA3 variants?
 
=E2=80=8BNo.=E2=80=8B
 
=E2=80=8BNIST EdDSA withj SHA-2 is in the = CABForum list of approved algorithms. But I can't see there being = momentum behind uses of those curves in the future. I think we have made = a decision to focus on Curve-X
 
[JLS] I am having a bit of a problem with = this.  EdDSA w/ 25519 uses SHA-2, but w/448 uses SHA-3.  The = blanket statement of Curve-X uses SHA-2 is not correc.t
 
Jim

And EdDSA is not = NIST-approved (nor either of the curves). I think Phil meant ECDSA = there.

Yoav
= --Apple-Mail=_9232D628-6F36-4C2A-B6D5-D94F42AD53E0-- --Apple-Mail=_C948799E-0AF7-4661-A9C2-975A27AED817 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYsJ/hAAoJELhJCxUKWMyZqfQH/RyxDaP/NreHumbWmJAsFckK 9LYyCXrU8jRD4vojTHrq01N6ZRTHEpDWuX1WVd/eM117DAzG77e59U05CmPBFaJk WU0e9otd/SiXWaV+KR5/xdz/+PEc5aazsEn8TSE5q90+M3TwbWtXRFk2C8nBBbET IXo8sPcRQBbaTuO9Qwqn7HMEQz5noTSboRKpwvteTLcUxYERoYY+NfLlXPGkITpg jSqrup73jpE/+l7jMFJvivmyR/Ai3F23qtQgTqh5bJ0PpPfSXinILnJzt5m1Ma0Y PEbmO4+zOPHWBtTMMPd7ydpk4i6x9ExD3CgFsOLzk9GE9nv8yxw7PEIrOeYg1KM= =ULjW -----END PGP SIGNATURE----- --Apple-Mail=_C948799E-0AF7-4661-A9C2-975A27AED817-- From nobody Fri Feb 24 13:22:34 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDFC129511 for ; Fri, 24 Feb 2017 13:22:33 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZKnl0tn7xYfF for ; Fri, 24 Feb 2017 13:22:32 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 EE13B1294F8 for ; Fri, 24 Feb 2017 13:22:31 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id i66so8392464yba.1 for ; Fri, 24 Feb 2017 13:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kSRP/7MutQPCrQ7o7fNcmUPsUwvqdCfSaSH/yqW6044=; b=iEDbd/bYgg6IGqcDvphri0sg/V+g3HrXIgNEam9fuP/Xj/zO7qweLprzwWLYUB014g XQMtucElXkV/U2LrhSs3V0BlgtXrxAw5NyONabu2qpQyr6ULZVcfnSxAiFFc/dhx4zcU sB2LMGYBjVbr07Y4EwrXODzVLbwaUQ+NsYcS4oZ53+fRX7T55c9Qu6mCEhksYvb0vc8D Qtzo6a++Jp5jDXk5oMtshNMBaPkpz2wIS6nhyWqHf9izXFUwANLlTLavQWpE40FL3+Zh ZQ1oI4W+G+JQu2lyOHhg1Dmnzaz70aChxzCfSdMjsu/IrzFFtm5IbGHz1fLo3FPDvtEe V8ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kSRP/7MutQPCrQ7o7fNcmUPsUwvqdCfSaSH/yqW6044=; b=e7SbFlA0UmK91RA7bwkGcnr7P5H7xp0lIozboMvSRKNNSzbnNJQmPn6whVVnHcvzCz 6PF3k0eYOBq1uoJm9KbiAI/WNwkLWePbMTRiRGIJR8P9Ju1ps0+ReRexEqeedL8eUH1j 3RLm31gxYWShtjGQg8Cr1Mgk+GNtGyE/wRMd6ccwf3whA+7+/2i+DcFGy53axsTXi6eL wz5iSxbwUjcdUruDwMXq8S6TTuw7jq5nxSQnkWQ3241RwtUlT05LT9dKQ+Tbh9yXbLop 13ERGkjaCjZyF9E25vAhyz6FOjjxjFL2Hq01K5aoeJMKYe98XiK98hOpUNfgIMwJXiv6 AlsA== X-Gm-Message-State: AMke39kC3h07YvlYa4iTVuxMt8lZZsc3Z7S10DLbIuHDmIHAF9FVqM/IXhCAfIuFxVbb+zGR0vczGqsbdG0tgQ== X-Received: by 10.37.181.25 with SMTP id p25mr3270256ybj.56.1487971351204; Fri, 24 Feb 2017 13:22:31 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Fri, 24 Feb 2017 13:22:30 -0800 (PST) In-Reply-To: References: <001301d28ee0$f88526e0$e98f74a0$@augustcellars.com> From: Phillip Hallam-Baker Date: Fri, 24 Feb 2017 16:22:30 -0500 X-Google-Sender-Auth: AArMsFSbcUixZQaYJumf78oVxwc Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=f403045e6ed0d3176d05494d53e5 Archived-At: Cc: SPASM , Jim Schaad Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 21:22:34 -0000 --f403045e6ed0d3176d05494d53e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2017 at 4:04 PM, Yoav Nir wrote: > > On 24 Feb 2017, at 23:00, Jim Schaad wrote: > > > > *From:* Spasm [mailto:spasm-bounces@ietf.org ] *O= n > Behalf Of *Phillip Hallam-Baker > *Sent:* Friday, February 24, 2017 12:54 PM > *To:* Yoav Nir > *Cc:* SPASM > *Subject:* Re: [Spasm] Add SHA-3 to PKIX > > On Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir wrote: > > =E2=80=8B2. Good question and was the reason I had been holding off on SH= A-3. > > I want both of course. But Curve-X requires a bit more prep than SHA-3. > > > The two EdDSA curves I understand. But what about ECDSA with the NIST > curves? Currently each of the three curves (P-256, P-384, and P-521) is > used with one of the SHA2 variants. Don=E2=80=99t you want them with SHA3= variants? > > > =E2=80=8BNo.=E2=80=8B > > =E2=80=8BNIST EdDSA withj SHA-2 is in the CABForum list of approved algor= ithms. > But I can't see there being momentum behind uses of those curves in the > future. I think we have made a decision to focus on Curve-X > > [JLS] I am having a bit of a problem with this. EdDSA w/ 25519 uses > SHA-2, but w/448 uses SHA-3. The blanket statement of Curve-X uses SHA-2 > is not correc.t > > Jim > > > And EdDSA is not NIST-approved (nor either of the curves). I think Phil > meant ECDSA there. > > =E2=80=8BNo, I don't care about the NIST curves or algorithms at this point= . Just more legacy. I thought I lost the SHA-3 battle on EdDSA. Glad to see I was wrong. Yep, doing SHA-3 for 448 makes sense as you want to use SHAKE, its the primitive designed to do what the signature needs. --f403045e6ed0d3176d05494d53e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Fe= b 24, 2017 at 4:04 PM, Yoav Nir <ynir.ietf@gmail.com> wrot= e:

On 24 Feb 2017, at 2= 3:00, Jim Schaad <ietf@augustcellars.com> wrote:

=C2=A0
=C2= =A0
From:=C2=A0Spasm [mailto:spasm-bounces@ietf.org]=C2=A0On Behalf Of<= span class=3D"m_-2073077896146846724Apple-converted-space">=C2=A0Phillip Hallam-Baker
Sent:=C2=A0Friday, February 24, 2017 12:54 PM
To:=C2=A0<= /span>Yoav Nir <ynir.ietf@gmail.com&g= t;
Cc:=C2=A0SPASM <SPASM@ietf.org>Subject:=C2=A0Re: [Spasm] Add SHA-3 to PKIX
=C2=A0
On Fri, Feb 24, 2017 at 3:40 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
=E2=80=8B2. Good question and was the reason = I had been holding off on SHA-3.=C2=A0
=C2=A0
=C2=A0
The two EdDSA curves I understand. But what about ECDSA with the NIST = curves? Currently each of the three curves (P-256, P-384, and P-521) is use= d with one of the SHA2 variants. Don=E2=80=99t you want them with SHA3 vari= ants?
=C2=A0
= =E2=80=8BNo.=E2=80=8B
=C2=A0
=E2=80=8BNIST E= dDSA withj SHA-2 is in the CABForum list of approved algorithms. But I can&= #39;t see there being momentum behind uses of those curves in the future. I= think we have made a decision to focus on Curve-X
=C2=A0
[JLS] I am having a bit of = a problem with this.=C2=A0 EdDSA w/ 25519 uses SHA-2, but w/448 uses SHA-3.= =C2=A0 The blanket statement of Curve-X uses SHA-2 is not correc.t
=C2=A0
Jim<= /span>

And EdDSA is not NIST-approved (nor either of the= curves). I think Phil meant ECDSA there.


=E2=80=8BNo, I don&= #39;t care about the NIST curves or algorithms at this point. Just more leg= acy.

=

I thought I lost the SHA-3 bat= tle on EdDSA. Glad to see I was wrong.

Yep, doing SHA-3 for 448 makes sense as you want to use SHAKE= , its the primitive designed to do what the signature needs.


--f403045e6ed0d3176d05494d53e5-- From nobody Mon Feb 27 05:15:41 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B94129F66 for ; Mon, 27 Feb 2017 05:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 ALhdWvNYHpWL for ; Mon, 27 Feb 2017 05:15:38 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7ECA129678 for ; Mon, 27 Feb 2017 05:15:37 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 96ACBA3B55; Mon, 27 Feb 2017 13:15:38 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.156]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1RDFaK8005538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Feb 2017 08:15:37 -0500 Message-ID: <1488201335.2987.25.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Phillip Hallam-Baker , SPASM Date: Mon, 27 Feb 2017 14:15:35 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 27 Feb 2017 13:15:38 +0000 (UTC) Archived-At: Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:15:40 -0000 On Fri, 2017-02-24 at 11:47 -0500, Phillip Hallam-Baker wrote: > All, > > In the wake of the SHA-1 break, the WebPKI is now down to one digest > algorithm. Given the role of the WebPKI, we need two algorithms based > on different principles. > > SHA-3 is the obvious choice. NIST has allocated OIDs but they have > parameters and so it is not quite a straight drop in replacement for > SHA-2. Hi, Do you here mean the SHAKE algorithms or the SHA3 ones? As far as I see in the NIST web site, the SHA3 ones require no parameters [0]. The SHAKE ones, indeed they do. [0]. http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.h tml > * CABForum can't act until there is an RFC to cite. > * HSM vendors won't produce product until there is a demand. I'd add here also: * TLS 1.3 did not include the algorithm in the current draft nor plans to include it until there is adoption > I suggest the following as an approach for SHA-3/RSA > > 1) Submit a SHA-3/RSA draft to LAMPS > 2) On passing  > 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm Certainly a good idea. regards, Nikos From nobody Mon Feb 27 05:41:21 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C900129FB5 for ; Mon, 27 Feb 2017 05:41:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=nistgov.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 ExgQhQ6iiCct for ; Mon, 27 Feb 2017 05:41:12 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0136.outbound.protection.outlook.com [23.103.201.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E353129FB7 for ; Mon, 27 Feb 2017 05:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lde+7N/DDQZokE3NH7bQ2Uf2i/S8iLAZ3Y7l9HfwcYk=; b=kcfh61qiYuhdjAry7FOtoHo3NlCQjUucucjCx6CloO83C+AU489PqvYSM6eDbgKGsVZvKMOHRVQCPNvCIhIv1NTrn8u4syD0Vb6VMBFB0RTpn4Knhl44IkyxcwNoDNbLxO2y3rpxQ/y10ARvbEHA1xSqzQg5dCJ6DrDBTHm9Wdg= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1462.namprd09.prod.outlook.com (10.173.191.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Mon, 27 Feb 2017 13:41:11 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0933.016; Mon, 27 Feb 2017 13:41:11 +0000 From: "Dang, Quynh (Fed)" To: Nikos Mavrogiannopoulos , Phillip Hallam-Baker , SPASM Thread-Topic: [Spasm] Add SHA-3 to PKIX Thread-Index: AQHSjr23sHtxAP7a9ECOjKgSPzSmO6F82a2A//+zUgA= Date: Mon, 27 Feb 2017 13:41:10 +0000 Message-ID: References: <1488201335.2987.25.camel@redhat.com> In-Reply-To: <1488201335.2987.25.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.219.8] x-ms-office365-filtering-correlation-id: 8552695c-72c3-4698-3889-08d45f164a94 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462; x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:7dARJBuf0GHlnUUfWI7VMHrlwui6fQNc7TI1WJ9RYH8GgYBmGGF+eLfYQ0XLtMZZIEGdm3rijV+i504vSqccXAFw6GoEWYl0QM7lqo6vyDR1PS45nF5QTjukuTcacj0IX18eQI44zv7v1FXiY3Rp+LShEc1wM5HTFLBnqki7ZURg6qlWG3VOBTLjbkHEODdbq6EUfHhJa2P579WaYRO+oVPpFkJKskmjCj3g9R9j6D7oMZu/V6kFEe8W4iLY/uoGLCfRfkKn0OfXVbJyie2jHmk3KFNH80pCm/CDxhaD54U5sEyKjxVlc3Lck8vk/UXKS784E0ipPWyLanIwU/2vvw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(131022147185803); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462; x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39840400002)(39850400002)(39410400002)(189002)(377424004)(24454002)(377454003)(199003)(86362001)(105586002)(106116001)(38730400002)(106356001)(54356999)(53546006)(6506006)(6436002)(606005)(8676002)(101416001)(6116002)(102836003)(53936002)(3846002)(966004)(2950100002)(6246003)(68736007)(92566002)(2906002)(54896002)(122556002)(6306002)(189998001)(76176999)(4001350100001)(236005)(8936002)(97736004)(6512007)(5660300001)(81156014)(81166006)(36756003)(66066001)(99286003)(2900100001)(3280700002)(3660700001)(25786008)(83506001)(50986999)(229853002)(7736002)(7906003)(77096006)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D4D995753109Eqdangnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2017 13:41:10.9037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462 Archived-At: Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:41:17 -0000 --_000_D4D995753109Eqdangnistgov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Spasm > on beha= lf of Nikos Mavrogiannopoulos > Date: Monday, February 27, 2017 at 8:15 AM To: Phillip Hallam-Baker >, SPASM > Subject: Re: [Spasm] Add SHA-3 to PKIX On Fri, 2017-02-24 at 11:47 -0500, Phillip Hallam-Baker wrote: All, In the wake of the SHA-1 break, the WebPKI is now down to one digest algorithm. Given the role of the WebPKI, we need two algorithms based on different principles. SHA-3 is the obvious choice. NIST has allocated OIDs but they have parameters and so it is not quite a straight drop in replacement for SHA-2. Hi, Do you here mean the SHAKE algorithms or the SHA3 ones? As far as I see in the NIST web site, the SHA3 ones require no parameters [0]. The SHAKE ones, indeed they do. [0]. http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.h tml Hi Nikos, We could use the OIDs for the SHAKEs which do not have output length parame= ter with an explicit policy being that output length of SHAKE128 is 256 bit= s and output length of SHAKE256 is 512 bits. Quynh. * CABForum can't act until there is an RFC to cite. * HSM vendors won't produce product until there is a demand. I'd add here also: * TLS 1.3 did not include the algorithm in the current draft nor plans to include it until there is adoption I suggest the following as an approach for SHA-3/RSA 1) Submit a SHA-3/RSA draft to LAMPS 2) On passing 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm Certainly a good idea. regards, Nikos _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_D4D995753109Eqdangnistgov_ Content-Type: text/html; charset="us-ascii" Content-ID: <34EA6A4CCCCC5A40943796D732760EA8@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable


From: Spasm <spasm-bounces@ietf.org> on behalf of Nikos Ma= vrogiannopoulos <nmav@redhat.com&= gt;
Date: Monday, February 27, 2017 at = 8:15 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>, SPASM <= ;SPASM@ietf.org>
Subject: Re: [Spasm] Add SHA-3 to P= KIX

On Fri, 2017-02-24 at 11:47 -0500, Phillip Hallam-Baker wrote:
All,
In the wake of the SHA-1 break, the WebPKI is now down to one digest
algorithm. Given the role of the WebPKI, we need two algorithms based<= /div>
on different principles.
SHA-3 is the obvious choice. NIST has allocated OIDs but they have
parameters and so it is not quite a straight drop in replacement for
SHA-2.

Hi,
Do you here mean the SHAKE algorithms or the SHA3 ones? As far as I
see in the NIST web site, the SHA3 ones require no parameters [0]. The=
SHAKE ones, indeed they do.

Hi Nikos,

We could use the OIDs for the SHAKEs which do not have output length p= arameter with an explicit policy being that output length of SHAKE128 is 25= 6 bits and output length of SHAKE256 is 512 bits.

Quynh. 


* CABForum can't act until there is an RFC to cite.
* HSM vendors won't produce product until there is a demand.

I'd add here also:
* TLS 1.3 did not include the algorithm in the current draft nor plans=
to include it until there is adoption


I suggest the following as an approach for SHA-3/RSA
1) Submit a SHA-3/RSA draft to LAMPS
2) On passing 
3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm

Certainly a good idea.

regards,
Nikos

_______________________________________________
Spasm mailing list

 --_000_D4D995753109Eqdangnistgov_-- From nobody Mon Feb 27 06:15:44 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC00129FE7 for ; Mon, 27 Feb 2017 06:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 n6jRtgQAC6j1 for ; Mon, 27 Feb 2017 06:15:39 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 9214D129FE6 for ; Mon, 27 Feb 2017 06:15:34 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id m124so12590244oig.1 for ; Mon, 27 Feb 2017 06:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LX62nLisAzsLK4ho4lSuLBE+aTN9Goh7w16G0xEZOH0=; b=YrcTvzoL/NktJ0/JuDEefEpsWu2ltGhdniyhD1PKpIYkz2Ge+tqJZu3YHf79U4k/08 A5rgQk7sGqG2zPWlmIaBvGz5CTxvJeYouw4DJXXvVAlqhOcB/N2e6/4g1Lel7PkZrQih 6YPNwavlA8+mSdSVNeyy37vvJq+MibFH/rO3+rJVtMsFnnpUpRe3B8kvwTXkt/bKEQb5 Gdi6zL8D0vqJPlBWlOUj8un/AMPBxIlMxSVRavDodG5prtovFRiWu6HtKXpU18kUFAy4 Sie/wuxkHtvMYlHRpipDhPiYQx09szUbXXJ37S/L5bIE+o32mI954ENZsAxvtK/YmsF9 /laA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LX62nLisAzsLK4ho4lSuLBE+aTN9Goh7w16G0xEZOH0=; b=Qsf/8X6ieJjvfzajIlzYRGDQtjBKPcTycqDXxxvYYhDBrVa981dbcoZ2NrHOr+JBXI WA3CQbZij6U3VUTm/pIxB3iHO0nzsaCX59JglynEF5mf0ZKsBlxd052pBC51qYjmZ6Yw ZgZMUb1JKjorOeBdzF1SkIUW05MIsQHADqBXNufMsE4IoxSIKJ+LjlPUxfTAEIQChy94 OjWjhpyL8Dst1j3aNPCOZF8Fp4nPDyhQrWXefPO7UBcw6e/zgHJjZh5WWm/qqTZ+4qKP 9H7ur82vIcBXbqRA7sjrqWGB5HYF2m6jF3nKBF9crmaCeOqEQvFMXjeQ4TP/GsZ3DjX3 l3Og== X-Gm-Message-State: AMke39mQzG59PFbtcEDRuyqx2iAibwogMFoI2rfpZ6MdTtNSHU4bxwYjd/o6dH8u/rBt+BhRJWQfGOO4b64wPA== X-Received: by 10.202.241.70 with SMTP id p67mr7448757oih.67.1488204933815; Mon, 27 Feb 2017 06:15:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.116 with HTTP; Mon, 27 Feb 2017 06:15:33 -0800 (PST) In-Reply-To: References: From: Peter Bowen Date: Mon, 27 Feb 2017 06:15:33 -0800 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:15:41 -0000 On Fri, Feb 24, 2017 at 8:47 AM, Phillip Hallam-Baker wrote: > In the wake of the SHA-1 break, the WebPKI is now down to one digest > algorithm. Given the role of the WebPKI, we need two algorithms based on > different principles. > > SHA-3 is the obvious choice. NIST has allocated OIDs but they have > parameters and so it is not quite a straight drop in replacement for SHA-2. Where do you see that there are parameters called for in the NIST spec? On http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html, I see: nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) } sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 } id-dsa-with-sha3-224 ::= { sigAlgs 5 } id-dsa-with-sha3-256 ::= { sigAlgs 6 } id-dsa-with-sha3-384 ::= { sigAlgs 7 } id-dsa-with-sha3-512 ::= { sigAlgs 8 } id-ecdsa-with-sha3-224 ::= { sigAlgs 9 } id-ecdsa-with-sha3-256 ::= { sigAlgs 10 } id-ecdsa-with-sha3-384 ::= { sigAlgs 11 } id-ecdsa-with-sha3-512 ::= { sigAlgs 12 } id-rsassa-pkcs1-v1_5-with-sha3-224 ::= { sigAlgs 13 } id-rsassa-pkcs1-v1_5-with-sha3-256 ::= { sigAlgs 14 } id-rsassa-pkcs1-v1_5-with-sha3-384 ::= { sigAlgs 15 } id-rsassa-pkcs1-v1_5-with-sha3-512 ::= { sigAlgs 16 } Yes, SHAKE has parameters, but SHA3-* does not AFAICT. > Deployment of SHA-2 took 15 years, in part because nobody saw the need to > deploy SHA-2 until after the Wang attack of 2005. There are many moving > parts in this system and one of the major problems is that many parties wait > for the others to act before they act. > > * CABForum can't act until there is an RFC to cite. > * HSM vendors won't produce product until there is a demand. > > There is of course the complicating factor of Curve-X ECC. I note that > draft-ietf-curdle-pkix-newcurves is in WG last call. I was previously > waiting on that draft passing the IESG to raise Curve-X in CABForum. > > I suggest the following as an approach for SHA-3/RSA > > 1) Submit a SHA-3/RSA draft to LAMPS Why not include (FF)DSA and ECDSA as well? They might be as en vogue as EdDSA but are something handled by HSMs today. > 2) On passing > 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm > > The Curve-X work could happen in parallel and would follow the same > approach. I would expect the two would quickly get in sync. Thanks, Peter From nobody Mon Feb 27 06:23:03 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824CE12A015 for ; Mon, 27 Feb 2017 06:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 b8B-oJqx5s2V for ; Mon, 27 Feb 2017 06:23:00 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED98129FF5 for ; Mon, 27 Feb 2017 06:23:00 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 599D6552CE; Mon, 27 Feb 2017 14:23:01 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.156]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1REMwFn026136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Feb 2017 09:23:00 -0500 Message-ID: <1488205378.2987.28.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Russ Housley , Tim Ruehsen Date: Mon, 27 Feb 2017 15:22:58 +0100 In-Reply-To: <46661456-29AE-4792-84B9-0A6C59767CB1@vigilsec.com> References: <1544074.0Z1XjAZpMm@blitz-lx> <46661456-29AE-4792-84B9-0A6C59767CB1@vigilsec.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 27 Feb 2017 14:23:01 +0000 (UTC) Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:23:02 -0000 On Thu, 2017-01-19 at 10:21 -0500, Russ Housley wrote: > On Jan 19, 2017, at 4:22 AM, Tim Ruehsen wrote: > > > Hi, > > > > as an implementer of IDN aware client software I am seeking for > > clarification. > > > > Punycode conversion of an IDN always comes with preprocessing > > steps. These  > > steps influence the resulting punycode in a way that a reverse > > procedure  > > (punycode decoding) doesn't result in the original IDN. > > That leads to incompatibilities between IDNA2003 and IDNA2008, > > addressed by  > > Unicode technical report #46 (TR46)[1]. This technical report > > defines two  > > preprocessing procedures, namely 'transitional' and 'non- > > transitional'. > > > > Currently the open source client software (e.g. curl, wget) goes in > > the  > > direction of using TR46's 'non-transitional', which is very close > > to IDNA2008  > > + a few flaws fixed. > > > > Maybe you could address this also in your draft, to clarify > > implementation  > > work. > > > > Just a (often cited) example from the german locale: > > > > IDNA2003 translates 'faß.de' to 'fass.de'. That is not revertable > > by the means  > > of IDNA2003. That means using IDN2003 to compare a certificates > > validity would  > > match 'faß.de' and 'fass.de', both have different owners... no > > chance to do it  > > right. > > > > IDNA2008 fixes this and translates 'faß.de' to 'xn--fa-hia.de', but > > doesn't  > > address other peculiarities. > > > > > > Having the above in mind, I would appreciate it if you clearly say: > > > > 1. IDNs used in certs have to be punycode-encoded using TR46 non- > > transitional  > > processing (that is where we all want be to some time in the > > future). > > As you say, that would be equivalent to telling people to use > IDNA2008 plus some stuff not agreed by the IETF consensus > process.  Since this document will be an IETF consensus document > (once approved), I think it better to stick to IDNA2088. I think Tim's point here is that that the IDNA2008 doesn't define the actual pre-processing steps needed prior to convert a unicode string to punycode. If for example a non-ascii all caps string is encountered one would have to pre-process it in order to use IDNA2008. This is not something we can leave up to the implementer. We have to either use TR46 or define what other preprocessing has to be used. IDNA2003 for example maps "ÖBB.at" to "öbb.at", IDNA2008 doesn't define what mapping is to be used. You can see that omission in the rationale for the TR46, in the Mapping section 1.3.1 of:  http://unicode.org/reports/tr46/ regards, Nikos From nobody Mon Feb 27 06:28:31 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9E3129955 for ; Mon, 27 Feb 2017 06:28: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, UNPARSEABLE_RELAY=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 XiXQgyUtYtUg for ; Mon, 27 Feb 2017 06:28:23 -0800 (PST) Received: from rmdccgokm1.reyn.mcr.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:402:430::9708:41f4]) (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 8EE7512A046 for ; Mon, 27 Feb 2017 06:28:16 -0800 (PST) Received: (korumail 11549 invoked from network); 27 Feb 2017 14:28:14 -0000 Received: from unknown (HELO maileu.comodo.net) () by 0 with SMTP; 27 Feb 2017 14:28:14 -0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201702271428120099; Mon, 27 Feb 2017 14:28:12 +0000 To: Peter Bowen , Phillip Hallam-Baker References: From: Rob Stradling Message-ID: Date: Mon, 27 Feb 2017 14:28:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.5 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:28:28 -0000 On 27/02/17 14:15, Peter Bowen wrote: > On Fri, Feb 24, 2017 at 8:47 AM, Phillip Hallam-Baker > wrote: >> In the wake of the SHA-1 break, the WebPKI is now down to one digest >> algorithm. Given the role of the WebPKI, we need two algorithms based on >> different principles. >> >> SHA-3 is the obvious choice. NIST has allocated OIDs but they have >> parameters and so it is not quite a straight drop in replacement for SHA-2. > > Where do you see that there are parameters called for in the NIST spec? If there are no parameters, then there still needs to be a specification that says how to encode "no parameters" in an AlgorithmIdentifier! Is it like this... https://tools.ietf.org/html/rfc3279#section-2.2.1 "When any of these three OIDs appears within the ASN.1 type AlgorithmIdentifier, the parameters component of that type SHALL be the ASN.1 type NULL." ? Or like this... https://tools.ietf.org/html/rfc3279#section-2.2.3 "When the ecdsa-with-SHA1 algorithm identifier appears as the algorithm field in an AlgorithmIdentifier, the encoding MUST omit the parameters field." ? Or something else? > On http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html, I see: > > nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) > us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) } > sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 } > > id-dsa-with-sha3-224 ::= { sigAlgs 5 } > id-dsa-with-sha3-256 ::= { sigAlgs 6 } > id-dsa-with-sha3-384 ::= { sigAlgs 7 } > id-dsa-with-sha3-512 ::= { sigAlgs 8 } > > id-ecdsa-with-sha3-224 ::= { sigAlgs 9 } > id-ecdsa-with-sha3-256 ::= { sigAlgs 10 } > id-ecdsa-with-sha3-384 ::= { sigAlgs 11 } > id-ecdsa-with-sha3-512 ::= { sigAlgs 12 } > > id-rsassa-pkcs1-v1_5-with-sha3-224 ::= { sigAlgs 13 } > id-rsassa-pkcs1-v1_5-with-sha3-256 ::= { sigAlgs 14 } > id-rsassa-pkcs1-v1_5-with-sha3-384 ::= { sigAlgs 15 } > id-rsassa-pkcs1-v1_5-with-sha3-512 ::= { sigAlgs 16 } > > Yes, SHAKE has parameters, but SHA3-* does not AFAICT. > >> Deployment of SHA-2 took 15 years, in part because nobody saw the need to >> deploy SHA-2 until after the Wang attack of 2005. There are many moving >> parts in this system and one of the major problems is that many parties wait >> for the others to act before they act. >> >> * CABForum can't act until there is an RFC to cite. >> * HSM vendors won't produce product until there is a demand. >> >> There is of course the complicating factor of Curve-X ECC. I note that >> draft-ietf-curdle-pkix-newcurves is in WG last call. I was previously >> waiting on that draft passing the IESG to raise Curve-X in CABForum. >> >> I suggest the following as an approach for SHA-3/RSA >> >> 1) Submit a SHA-3/RSA draft to LAMPS > > Why not include (FF)DSA and ECDSA as well? They might be as en vogue > as EdDSA but are something handled by HSMs today. > >> 2) On passing >> 3) Submit a CABForum Ballot to adopt SHA-3 as a approved algorithm >> >> The Curve-X work could happen in parallel and would follow the same >> approach. I would expect the two would quickly get in sync. > > Thanks, > Peter -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Feb 27 06:54:40 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9FD12A09A for ; Mon, 27 Feb 2017 06:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 dKqJP0u8Oqrs for ; Mon, 27 Feb 2017 06:54:38 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 56FA6129E53 for ; Mon, 27 Feb 2017 06:54:38 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id l138so12979175ywc.0 for ; Mon, 27 Feb 2017 06:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LpVGJ+WTJNZleys7ECJ7jk0k2ou04k4RWIz3tDnWh/4=; b=K3llD4OS95IR/GfG7sSb+RUEyRe2rXGfsFFXSDbrbOCJh+n36qu1q+z62ttsoTfh/f VEb3OIXP2UM3UJxSKkg3Au+w74fkmxHtpuGXZZ45R3Bhlp1AXlS7O89E59xoUWNzjQxr umIMq8dLqx8N2/GTt0LG2cvnba+qxKCcZ7PM17wyVCT1t133/Uyq3d/EY4hibCMO2jn3 Lq3gVhlPh/skp6727qnTVr8qDMZMTOYN670vqkHc4dozV3gVcb7xGExm5MxpGmIjjyh2 paTkzlaafd2U0Cqv8XzQ9x/cAMWqncXnvd3t6FP5FzuTf0m7adPvSCZ+hx9NCoigIGVi 2UvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LpVGJ+WTJNZleys7ECJ7jk0k2ou04k4RWIz3tDnWh/4=; b=ndthmb2jTln6UfvfiKVRwJtDriSOIkPqIGHlAFc04HUiMUnB+CBMnAIo9Pbc0kYAGO 6nM3hzv7KJMI06sA1XWgzb1FX7dif6G4aDxxaJ68VeoSr5ndEyk/ciu6CSOT0AIGVQUy LP+xSzDXjBgmtZUjr3myYOee4upE+Lpa1JrwRZ+u5Y2ElL3jqMRNEAoxHRbVh8VJjw2D jI7rgBf58vjvRGt8l470+Z1JnwKOwzYIVbVSahgcjXRqnJyntBebDZ20/2dPz/4yUaA8 mJvZukG3l1xgrntKXR7+B2UFNOd4UUfEkxU4HX2cr5X6QUXTs9TF+3iEofF/qrAowJxk rJRA== X-Gm-Message-State: AMke39kbEbY+hidBOe0TpM0H77nVI/HLIM8/kpxwnhd1R89OFgBHfYAwW6giINVRxslkK4/tf97LIzQw4pVCig== X-Received: by 10.37.234.17 with SMTP id p17mr552242ybd.122.1488207277375; Mon, 27 Feb 2017 06:54:37 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Mon, 27 Feb 2017 06:54:36 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 27 Feb 2017 09:54:36 -0500 X-Google-Sender-Auth: mVJCuJQCHHZHH9L-_-SnQZEdFgI Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=f403045daa041ecd2005498442c8 Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:54:40 -0000 --f403045daa041ecd2005498442c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2017 at 9:15 AM, Peter Bowen wrote: > On Fri, Feb 24, 2017 at 8:47 AM, Phillip Hallam-Baker > wrote: > > In the wake of the SHA-1 break, the WebPKI is now down to one digest > > algorithm. Given the role of the WebPKI, we need two algorithms based o= n > > different principles. > > > > SHA-3 is the obvious choice. NIST has allocated OIDs but they have > > parameters and so it is not quite a straight drop in replacement for > SHA-2. > > Where do you see that there are parameters called for in the NIST spec? > > On http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html, > I see: > > nistAlgorithms OBJECT IDENTIFIER ::=3D { joint-iso-ccitt(2) country(16) > us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) } > sigAlgs OBJECT IDENTIFIER ::=3D { nistAlgorithms 3 } > > id-dsa-with-sha3-224 ::=3D { sigAlgs 5 } > id-dsa-with-sha3-256 ::=3D { sigAlgs 6 } > id-dsa-with-sha3-384 ::=3D { sigAlgs 7 } > id-dsa-with-sha3-512 ::=3D { sigAlgs 8 } > > id-ecdsa-with-sha3-224 ::=3D { sigAlgs 9 } > id-ecdsa-with-sha3-256 ::=3D { sigAlgs 10 } > id-ecdsa-with-sha3-384 ::=3D { sigAlgs 11 } > id-ecdsa-with-sha3-512 ::=3D { sigAlgs 12 } > > id-rsassa-pkcs1-v1_5-with-sha3-224 ::=3D { sigAlgs 13 } > id-rsassa-pkcs1-v1_5-with-sha3-256 ::=3D { sigAlgs 14 } > id-rsassa-pkcs1-v1_5-with-sha3-384 ::=3D { sigAlgs 15 } > id-rsassa-pkcs1-v1_5-with-sha3-512 ::=3D { sigAlgs 16 } > =E2=80=8BSomeone suggested this was an issue. Since they are a likely imple= menter, I assumed we at least need to tell them it isn't. I can't see a need for the parameters. But we do need to tell people the exact padding mode to use for PKIX. =E2=80=8B Why not include (FF)DSA and ECDSA as well? They might be as en vogue > as EdDSA but are something handled by HSMs today. =E2=80=8BMight as well specify the full set in any PKIX related draft. =E2=80=8B =E2=80=8BThey are certainly being used in the WebPKI.=E2=80=8B --f403045daa041ecd2005498442c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Fe= b 27, 2017 at 9:15 AM, Peter Bowen <pzbowen@gmail.com> wrote= :
On Fri, Feb 24, 2017 a= t 8:47 AM, Phillip Hallam-Baker
<phill@hallambaker.com> = wrote:
> In the wake of the SHA-1 break, the WebPKI is now down to one digest > algorithm. Given the role of the WebPKI, we need two algorithms based = on
> different principles.
>
> SHA-3 is the obvious choice. NIST has allocated OIDs but they have
> parameters and so it is not quite a straight drop in replacement for S= HA-2.

Where do you see that there are parameters called for in the NIST sp= ec?

On http://csrc.nist.gov/groups/= ST/crypto_apps_infra/csor/algorithms.html, I see:

nistAlgorithms OBJECT IDENTIFIER ::=3D { joint-iso-ccitt(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) }
sigAlgs OBJECT IDENTIFIER ::=3D { nistAlgorithms 3 }

id-dsa-with-sha3-224 ::=3D { sigAlgs 5 }
id-dsa-with-sha3-256 ::=3D { sigAlgs 6 }
id-dsa-with-sha3-384 ::=3D { sigAlgs 7 }
id-dsa-with-sha3-512 ::=3D { sigAlgs 8 }

id-ecdsa-with-sha3-224 ::=3D { sigAlgs 9 }
id-ecdsa-with-sha3-256 ::=3D { sigAlgs 10 }
id-ecdsa-with-sha3-384 ::=3D { sigAlgs 11 }
id-ecdsa-with-sha3-512 ::=3D { sigAlgs 12 }

id-rsassa-pkcs1-v1_5-with-sha3-224 ::=3D { sigAlgs 13 }
id-rsassa-pkcs1-v1_5-with-sha3-256 ::=3D { sigAlgs 14 }
id-rsassa-pkcs1-v1_5-with-sha3-384 ::=3D { sigAlgs 15 }
id-rsassa-pkcs1-v1_5-with-sha3-512 ::=3D { sigAlgs 16 }

=E2=80=8BSomeone suggested this was an issue. Since they are a likely imp= lementer, I assumed we at least need to tell them it isn't.

I can't see a need for the param= eters. But we do need to tell people the exact padding mode to use for PKIX= . =E2=80=8B

Why not include (= FF)DSA and ECDSA as well? They might be as en vogue
as EdDSA but are something handled by HSMs today.

=E2=80=8BMigh= t as well specify the full set in any PKIX related draft.
=E2=80=8B
=E2=80=8BThey are certainly be= ing used in the WebPKI.=E2=80=8B

--f403045daa041ecd2005498442c8-- From nobody Mon Feb 27 13:59:48 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3B1129431 for ; Mon, 27 Feb 2017 13:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 eFeiBwU6IIMn for ; Mon, 27 Feb 2017 13:59:45 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 CE629129426 for ; Mon, 27 Feb 2017 13:59:43 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n186so43423946qkb.3 for ; Mon, 27 Feb 2017 13:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=bCDBbAu3ZQqeK0VdJ02Ozc+cqdW9uo+qtNJgpE3WzAE=; b=Z03Kw88B+Ao4FihlwOzSQJdz4kZUz1IDNdF/3pDpgUl54qgSV/WIG2xmlhIA0wYjng 1vzBrZv9/LtbpWvG5ETptDQ11I7VsH42HGhY2pRa81FQHzgarWHfWjhXYFikN8VPShub 59dZOXnQAJngtGqIrOMtVbqkb+mf20JW41BXI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=bCDBbAu3ZQqeK0VdJ02Ozc+cqdW9uo+qtNJgpE3WzAE=; b=r213TKzRv8F8WTYDGPvqQVZRNH4WPI+X8mBI+r5Z5rdjVSHNyC2xQEccEeWWQV0gKg r1KF3lMoMTvj66Q0QbBUW0tEoWM0xYmlHJrvNFLkuqbCEua2aVT0MkWx0NC2hfv/Bwkl +nftGCzUQ1hyFBnPFvjjbMZXivdbo9b3+WHtyJa/QSNpwRQFECWlQUZM951UL3qsdCEC x0VeMsbCSJSqNr+4WbyBdh1LvrIGbcRTXW+f4GqpFAIZGSBKTlb0Xt+bsUAZ38Jze4Jx QuibYvQuXSQG7eAUmmanh7gCbCvoY9fpT17l8HmtB1r8fvVbZ5MHpg5/E4CNR+v2LPLc USZg== X-Gm-Message-State: AMke39nHN6tWL+raXN/WMmTpgVvTb/SlIjQYJ2GdJG2O2nbUDecWyZgpECUyfJRWhyxG8A== X-Received: by 10.200.36.207 with SMTP id t15mr19192248qtt.84.1488232782633; Mon, 27 Feb 2017 13:59:42 -0800 (PST) Received: from [172.16.0.18] ([96.231.229.68]) by smtp.gmail.com with ESMTPSA id j125sm11121812qkd.51.2017.02.27.13.59.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 13:59:41 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 27 Feb 2017 16:59:40 -0500 References: To: SPASM In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:59:46 -0000 > On Feb 27, 2017, at 9:28 AM, Rob Stradling = wrote: >=20 > If there are no parameters, then there still needs to be a = specification that says how to encode "no parameters" in an = AlgorithmIdentifier! I don=E2=80=99t recall seeing a spec that says what to do about the = parameters, but I helped with the RFC5480 update to RFC3279 and will = volunteer to do another one. spt= From nobody Mon Feb 27 14:07:12 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB00129412 for ; Mon, 27 Feb 2017 14:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 QHKLXyGAUC0f for ; Mon, 27 Feb 2017 14:07:09 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 CB6CD129415 for ; Mon, 27 Feb 2017 14:07:08 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id p77so46656412ywg.1 for ; Mon, 27 Feb 2017 14:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UmekYPrQ+GGc8FRN3G3pQKxOoepeGxbz95sW/scYSGs=; b=YLOiP4RKmViYrWF9UA91dpAgWV8+5+/uq5KYtjQT055wtsoTNAUdEO50A7oFtiSSSZ npox9AAqKj7V2JkyxKpvRgoxmfVsv20n1UCU4hQmyRVfVpZR4IjYBV6m7OFxkMrY6qPG KtLU3SWotPl4OojXmjflZ/QHh1U2DoPZ3Zpj2q/Zrreh9KFOgQcEkZkBMDRxdIc15PjR vl514+O79IRO61etq4OaG+A6kpKcPKtLG3RxRlKV+agrg5xe1Gicv1bBgVWFr0VUlVLr DXrQr16cs6fAF0UfUQlPdcYGApieyRXfKtMYxRYlUDo1kWeRPp7oSuIhwQIsbMs5ANs8 AArA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UmekYPrQ+GGc8FRN3G3pQKxOoepeGxbz95sW/scYSGs=; b=khVGANWd4apOBZwkp++O0OvRzTDCTK43roGeWckbn2nZBin7Kw6d9lCqt+vSe/SIg1 kOTgCkQRXgePpqMDL/vLUZ4YIPpfFU9TRZ7Zn1B1NCkm2SgAvmswbr38zLvmeiGQkKWz Gj76vSOV5lZTkJsFX8dq7rJrwXnOSObC5rbFCD66mnhJrGGJlQJx+WCFxXAqsycuj9h4 pnoB2puLGvXyA3p76mX+Bn55EznvNLOifLn6oV7pAUUHDN9DsVNPTtkmigFwh8CjnVlz pWAwqLJd0y8P7lmb/pJKYe99m7s7JmJ+ZLRP4+a/Ddjg4qb1Sul6vAdEQTxAYPyZHJNt CHKQ== X-Gm-Message-State: AMke39m4tWO7OYFy5iikHA4jQTn8NEehsNImjZCIYfjEpW8qPmG+fiYXwXkUNhujE/L6/IKpfI/GGF8g+48Csg== X-Received: by 10.129.153.19 with SMTP id q19mr13369314ywg.186.1488233228031; Mon, 27 Feb 2017 14:07:08 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Mon, 27 Feb 2017 14:07:07 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 27 Feb 2017 17:07:07 -0500 X-Google-Sender-Auth: 11o5a17WDnZHQAlS3CYTti9N_Ek Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=94eb2c0b7a5ce6995605498a4c7e Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:07:10 -0000 --94eb2c0b7a5ce6995605498a4c7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, If nobody has firm views, my preference would be as close to the way RSA is handled as is possible. But I am protecting my code :-) On Mon, Feb 27, 2017 at 4:59 PM, Sean Turner wrote: > > > On Feb 27, 2017, at 9:28 AM, Rob Stradling > wrote: > > > > If there are no parameters, then there still needs to be a specificatio= n > that says how to encode "no parameters" in an AlgorithmIdentifier! > > I don=E2=80=99t recall seeing a spec that says what to do about the param= eters, > but I helped with the RFC5480 update to RFC3279 and will volunteer to do > another one. > > spt > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --94eb2c0b7a5ce6995605498a4c7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tha= nks,=C2=A0

=
If nobody has = firm views, my preference would be as close to the way RSA is handled as is= possible. But I am protecting my code :-)

On Mon, Feb 27, 2017 at 4:59 PM, Sean = Turner <sean@sn3rd.com> wrote:

> On Feb 27, 2017, at 9:28 AM, Rob Stradling <rob.stradling@comodo.com> wrote:
>
> If there are no parameters, then there still needs to be a specificati= on that says how to encode "no parameters" in an AlgorithmIdentif= ier!

I don=E2=80=99t recall seeing a spec that says what to do about the = parameters, but I helped with the RFC5480 update to RFC3279 and will volunt= eer to do another one.

spt
______________________________= _________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--94eb2c0b7a5ce6995605498a4c7e-- From nobody Mon Feb 27 14:23:10 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31F5129432 for ; Mon, 27 Feb 2017 14:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snUfiCYm0Q8c for ; Mon, 27 Feb 2017 14:23:08 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CD31293FE for ; Mon, 27 Feb 2017 14:23:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DE632300447 for ; Mon, 27 Feb 2017 17:23:07 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v4iJB3hHDCPD for ; Mon, 27 Feb 2017 17:23:07 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 3B21B30024A for ; Mon, 27 Feb 2017 17:23:07 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 27 Feb 2017 17:23:07 -0500 References: To: SPASM In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 22:23:10 -0000 The work to add SHA-3 toPKIX (and possibly S/MIME) is not in the current = charter. In the past, Stephen was strongly against anything in the = LAMPS charter that did not have a high probablility of being = implemented. So, if this work was added to the charter, who would = implement it? Please speak on the list. Note that the current charter says: > In addition, the LAMPS Working Group may investigate other updates to=20= > the documents produced by the PKIX and S/MIME Working Groups, but the=20= > LAMPS Working Group shall not adopt any of these potential work items=20= > without rechartering. No such re-chartering is envisaged until one or=20= > more of the above work items have been successfully delivered to the = RFC=20 > editor queue.=20 Since our first document is in IESG Evaluation and the other two are in = WG Last Call, I would expect that this criteria will be met shortly. Russ From nobody Mon Feb 27 15:07:24 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A5C129448 for ; Mon, 27 Feb 2017 15:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 yLrFFXMvJIlS for ; Mon, 27 Feb 2017 15:07:22 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 9C59412944A for ; Mon, 27 Feb 2017 15:07:22 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id v200so47449422ywc.3 for ; Mon, 27 Feb 2017 15:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LB0RvfwM1jsiYoDgfDaG5Z2R/P39KO684YuEgd2Wcbk=; b=eXUn4hcwqn1bXTSn9MYsXC4OhOnXDFMlMDegaA2+4h/hzpc/LzkRhFEQxEYcc0ZPTr qb23dFNfE2TerpfmlHTcD3LX0/Q+SjFca0BRBINE3NDoAgdBk+F0i78m6snksucMYtS0 eqEjAi/LZyL33w40uMGxIOVn0W1i0VIrzlL9+LPlp94khOatOP/G6irRUVTdWgRt/4rz OUdDFrhBzzVH8MomdAWAs15SmnpbNNjBN0jW9zD1AXyGwKzD8OD9LNmJLA5N81CJG2VH OVo+ddCPpp7j2SrcWJrrN+Kw97ZBwixRYN5Ty7iXA4qyCmTi+aKyBd47uPsmvzQC+49z aESw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LB0RvfwM1jsiYoDgfDaG5Z2R/P39KO684YuEgd2Wcbk=; b=KuR3uOdPruNm+t4hep7ms5d86YbcBzQPndgKbEiq6LqvlOfe4NFPT1H5mOUlP8XuZH XNuCU6F0JSglWJIwyWxJ+fI8v9mEyi4K8eH/TB8+SzlvEcbxgafSJMdU3dpggzCzxV/2 Sf2HXMOPBU9E6uqo8d5hWMa1shrNs0AEIStX0Lzz43Ub9DJDvWxNyxhXsewxsnvCKwrr bUpKW4Et072gSmhrG9mIfokBSJQvYvmTa9Po9bz+XMiE9GHNWidnLpPLLd3H9YgwIPtr wVU3j3YqEfLZkpOCGLrh3U7S3g44JoSyIOPZOUtgu0LDwKCNr4IDzb3PAs2UqzI4bd3m G14Q== X-Gm-Message-State: AMke39nJHO8eqMtFby8kcyHkq4sHOx3f7ZSY338/dVOapmq3kFRoVrGFSlSCWb4AFCqtuxhMJ5ZSAUtrDmNXRw== X-Received: by 10.129.172.25 with SMTP id k25mr12905613ywh.165.1488236841898; Mon, 27 Feb 2017 15:07:21 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Mon, 27 Feb 2017 15:07:21 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 27 Feb 2017 18:07:21 -0500 X-Google-Sender-Auth: Jl0xy9G84VA9JWLqXo8GudR2z20 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=94eb2c1badfc4d9a4e05498b2472 Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 23:07:23 -0000 --94eb2c1badfc4d9a4e05498b2472 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2017 at 5:23 PM, Russ Housley wrote: > The work to add SHA-3 toPKIX (and possibly S/MIME) is not in the current > charter. In the past, Stephen was strongly against anything in the LAMPS > charter that did not have a high probablility of being implemented. So, = if > this work was added to the charter, who would implement it? Please speak > on the list. > > Note that the current charter says: > > > In addition, the LAMPS Working Group may investigate other updates to > > the documents produced by the PKIX and S/MIME Working Groups, but the > > LAMPS Working Group shall not adopt any of these potential work items > > without rechartering. No such re-chartering is envisaged until one or > > more of the above work items have been successfully delivered to the RF= C > > editor queue. > > Since our first document is in IESG Evaluation and the other two are in W= G > Last Call, I would expect that this criteria will be met shortly. =E2=80=8BI agree about not wanting to document stuff that is not going to b= e used. The point of this is to get a sounding from the parties that would be doing the deployment in CABForum. To pass a ballot has to have a majority of the Browsers and 2/3rd of the CAs. We can't hold a ballot on adding anything to the approved algorithms until we have the RFC. But we can have a motion of intent to do so. --94eb2c1badfc4d9a4e05498b2472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Fe= b 27, 2017 at 5:23 PM, Russ Housley <housley@vigilsec.com> wrote:
The work to add SHA-3 toPKIX (an= d possibly S/MIME) is not in the current charter.=C2=A0 In the past, Stephe= n was strongly against anything in the LAMPS charter that did not have a hi= gh probablility of being implemented.=C2=A0 So, if this work was added to t= he charter, who would implement it?=C2=A0 Please speak on the list.

Note that the current charter says:

> In addition, the LAMPS Working Group may investigate other updates to<= br> > the documents produced by the PKIX and S/MIME Working Groups, but the<= br> > LAMPS Working Group shall not adopt any of these potential work items<= br> > without rechartering. No such re-chartering is envisaged until one or<= br> > more of the above work items have been successfully delivered to the R= FC
> editor queue.

Since our first document is in IESG Evaluation and the other two are in WG = Last Call, I would expect that this criteria will be met shortly.

= =E2=80=8BI agree about not wanting to document stuff that is not going to b= e used.

The point of this= is to get a sounding from the parties that would be doing the deployment i= n CABForum. To pass a ballot has to have a majority of the Browsers and 2/3= rd of the CAs.
=
We can'= ;t hold a ballot on adding anything to the approved algorithms until we hav= e the RFC. But we can have a motion of intent to do so.



--94eb2c1badfc4d9a4e05498b2472--