From nobody Mon Jun 5 09:27:47 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 AFD60129534 for ; Mon, 5 Jun 2017 09:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 FXprWGFFJIok for ; Mon, 5 Jun 2017 09:27:43 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 A35D6129B52 for ; Mon, 5 Jun 2017 09:27:43 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id o65so139521771oif.1 for ; Mon, 05 Jun 2017 09:27:43 -0700 (PDT) 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=e1xH4iv5fF4prVywcV4tGkuSWWZ/tmy8EXzpdVWJJ2U=; b=CWSF2jCL58mBYRBYy68dmPkHMDsVuHhAB2NYTyMFJHAiya3hLUhadT7rwaf19f1Mqa 1VfLh1UqVZy/IhqwuKYiYVC0S6vtIKS0179Iqt9EbOFw3URxMfGTDxuE5YFlOaclK29S 6nxdT3gQxu2C3gDYTqyR6o347dQsMfA1fttwYzzfBxF8yC7EtwGiOjMfH44G2bvVdFf0 /dmB7H9cHmJ1QuTgDTT/69DDc70ZJVAx8ljvWH/9lkOO+nYmTqX38QQsQw5rbI/++IyD tb0qUmo7+4ag4ExflHTHiGRiFCPHLY/GFs8UIn1FkaZ25RW9Oof45NNrgHMgbPF/W+6f iVaA== 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=e1xH4iv5fF4prVywcV4tGkuSWWZ/tmy8EXzpdVWJJ2U=; b=FX6YKGlil3lUdQZ/uHc7s5cdcueePOmU+1gWRS/BmJS8BW06/6NigqeB2sEGtL1OxV xkliEvUj9Uu9rVbTd0oGTOld7o8O/JyhpogdZtIjuBoGMytd6hnEEpOTnjDI07S3Yd70 HfL6QpD+RwGPfymkAcctgz1tONE6zjils2iCn/dIFMgTsNvXG6YJt4e2TBlUGCfv7rfx NEzh3NCj+6BdzzpBWySB5fT6AKr9jnsBH2iyIauFfnKdecXFE15HOtuvzKMKACgTQHAb 5jgGJQEf7DtTQKndxuAnzkwG5qE8sy9CkEwpdtIFETCRpJv6iB2zV/OuSmcjsEU80ihT 3YAg== X-Gm-Message-State: AODbwcBce1cjAFg+91sQFLSgyTbkNIlKx3zgAnl6bmGQoFvpApXO08XP a2+FbBmOaVaaBHK/DTMmsnfSpp0weQ== X-Received: by 10.202.93.67 with SMTP id r64mr11526478oib.20.1496680063032; Mon, 05 Jun 2017 09:27:43 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Mon, 5 Jun 2017 09:27:42 -0700 (PDT) In-Reply-To: <2a5e2bbf-5441-f647-bb98-6578376e69a7@eff.org> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <2a5e2bbf-5441-f647-bb98-6578376e69a7@eff.org> From: Phillip Hallam-Baker Date: Mon, 5 Jun 2017 12:27:42 -0400 X-Google-Sender-Auth: _O6zsqs3IGYb0k_845rKL91h-fk Message-ID: To: Jacob Hoffman-Andrews Cc: SPASM , Rob Stradling Content-Type: multipart/alternative; boundary="001a113cf3067fe2ea055138fb61" Archived-At: Subject: Re: [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 16:27:46 -0000 --001a113cf3067fe2ea055138fb61 Content-Type: text/plain; charset="UTF-8" I fixed the 'is not empty' thing in Errata 4992. https://www.rfc-editor.org/errata_search.php?eid=4992 If you missed it, I am not surprised as I only noticed it after I was half way through entering it again. For some reason the Errata are not in numerical order. I would prefer not to change the description of the algorithm in the way you propose in what is an Errata. On Wed, May 31, 2017 at 8:39 PM, Jacob Hoffman-Andrews wrote: > Hi Phillip, > > Did you see this earlier mail from me? I think at least the "is not > empty" should be fixed before we submit a ballot to CA/Browser Forum. > Ideally I'd like to land the simpler language I proposed, but I'd be > fine with your offered text if we add the missing "is not empty." > > On 04/05/2017 12:43 PM, Jacob Hoffman-Andrews wrote: > > https://www.rfc-editor.org/errata_search.php?eid=4988 > > > > Rob Stradling said: > >> 2. Bug?: Shouldn't this... > >> o If A(X) is not null, and CAA(A(X)), then R(X) = > >> CAA(X), otherwise > >> > >> ...actually be this... > >> > >> o If A(X) is not null, and CAA(A(X)), then R(X) = > >> CAA(A(X)), otherwise > > A further edit: "and CAA(A(X))" should be "and CAA(A(X)) is not empty" > > > > Also, did you see my earlier suggestion on the list? I think now that we > > aren't tree-climbing on CNAME targets, we can express this algorithm in > > a more straightforward way that emphasizes its similarity to how other > > DNS records are looked up: > > > > ----- Proposal ----- > > Let CAA(X) be the record set returned by performing a CAA record > > query on the domain name X, according to the name server lookup > > algorithm specified in RFC 1034 section 4.3.2 (in particular including > > CNAME responses). Let P(X) be the domain name produced by removing the > > leftmost label of X. > > > > - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise > > - If P(X) is the root domain '.', then R(X) is empty, otherwise > > - R(X) = R(P(X)) > > > > ----- End proposal ----- > > --001a113cf3067fe2ea055138fb61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I f= ixed the 'is not empty' thing in Errata 4992.=C2=A0

https://www.rfc-editor.org/errata_search.php?eid=3D4992

If you miss= ed it, I am not surprised as I only noticed it after I was half way through= entering it again. For some reason the Errata are not in numerical order.<= /div>

I = would prefer not to change the description of the algorithm in the way you = propose in what is an Errata.

<= div class=3D"gmail_default">

=
On Wed, May 31, 2017 at 8:39 PM, Jacob Hoffman-A= ndrews <jsha@eff.org> wrote:
Hi= Phillip,

Did you see this earlier mail from me? I think at least the "is not empty" should be fixed before we submit a ballot to CA/Browser Forum.<= br> Ideally I'd like to land the simpler language I proposed, but I'd b= e
fine with your offered text if we add the missing "is not empty."=

On 04/05/2017 12:43 PM, Jacob Hoffman-Andrews wrote:
> https://www.rfc-editor.org/errata_s= earch.php?eid=3D4988
>
> Rob Stradling said:
>> 2. Bug?: Shouldn't this...
>>=C2=A0 =C2=A0o=C2=A0 If A(X) is not null, and CAA(A(X)), then R(X) = =3D
>>=C2=A0 =C2=A0 =C2=A0 CAA(X), otherwise
>>
>> ...actually be this...
>>
>>=C2=A0 =C2=A0o=C2=A0 If A(X) is not null, and CAA(A(X)), then R(X) = =3D
>>=C2=A0 =C2=A0 =C2=A0 CAA(A(X)), otherwise
> A further edit: "and CAA(A(X))" should be "and CAA(A(X)= ) is not empty"
>
> Also, did you see my earlier suggestion on the list? I think now that = we
> aren't tree-climbing on CNAME targets, we can express this algorit= hm in
> a more straightforward way that emphasizes its similarity to how other=
> DNS records are looked up:
>
> ----- Proposal -----
>=C2=A0 =C2=A0 Let CAA(X) be the record set returned by performing a CAA= record
> query on the domain name X, according to the name server lookup
> algorithm specified in RFC 1034 section 4.3.2 (in particular including=
> CNAME responses). Let P(X) be the domain name produced by removing the=
> leftmost label of X.
>
>=C2=A0 - If CAA(X) contains any CAA resource records, R(X) =3D CAA(X), = otherwise
>=C2=A0 - If P(X) is the root domain '.', then R(X) is empty, ot= herwise
>=C2=A0 - R(X) =3D R(P(X))
>
> ----- End proposal -----


--001a113cf3067fe2ea055138fb61-- From nobody Mon Jun 5 09:56:11 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 0242C127275 for ; Mon, 5 Jun 2017 09:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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_HI=-5, RP_MATCHES_RCVD=-0.001, 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=eff.org 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 IVblGDxLfQvY for ; Mon, 5 Jun 2017 09:56:07 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCDB120727 for ; Mon, 5 Jun 2017 09:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=yXqBtchLCsGcnkcxoCQQaoHVdGghPpVTiOMb9NQSdq0=; b=w5XnBDzHw3UaFVfwhfd068bKJYaCb7wcu79mabtF3Rv44YKh6WJ696f7Wp7Tsspad9cJZbb6wyNNxFa+5TqbULZJ/FI10hmwmu+VJdJKJ770JvdBvtaOStN05nObbQuOMLLPRbX3Qv6fubMWdHow1eK27tkRaRX+ErmDk7cqng8=; Received: ; Mon, 05 Jun 2017 09:56:06 -0700 To: Phillip Hallam-Baker Cc: SPASM , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <2a5e2bbf-5441-f647-bb98-6578376e69a7@eff.org> From: Jacob Hoffman-Andrews Message-ID: <2619514e-7f54-bc62-02fc-d4f228fee121@eff.org> Date: Mon, 5 Jun 2017 09:56:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 16:56:10 -0000 When I visit https://www.rfc-editor.org/errata_search.php?eid=4992, I still see this incorrect text: > If A(X) is not null, and CAA(A(X)), then R(X) = > CAA(A(X)), otherwise Specifically the clause "and CAA(A(X))" should be "and CAA(A(X)) is not empty". And yep, understandable about wanting to minimize changes to get this through promptly; I'm fine with that. From nobody Mon Jun 5 10:52:47 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 52C3E1294EF for ; Mon, 5 Jun 2017 10:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 nglCnWEceyco for ; Mon, 5 Jun 2017 10:52:43 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 C030D1274D0 for ; Mon, 5 Jun 2017 10:52:43 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l18so166715218oig.2 for ; Mon, 05 Jun 2017 10:52:43 -0700 (PDT) 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=ltPfVwP6GVU9RSNfsZqjJzGVX5hEBz0phnPqK9oVdM0=; b=SPWjzWLLez1g2I6o1tB5TX+cdJxH+bRjOchx+6Yd6ma1Ope0wJCpSQXJoJmsGv14c1 z7j7r87TZuUsYoFuR0XUKeMPPauIhYwydtXPL1tGtKU3xynsbrcBP6ZbQEeMFIGEB6qp ik8RmUHaYFDLgeCUeoVPCaP2a13SDJupPFBOJ2GzlelRd9Yd0HphIqY1vhga6cIYeiVe 8Qo8QnqtnOViMYwo4OQorrl0+m1TR7NaUHbjKMkO1q9MCqB5cHsVTyUyWH7vdzndbRnN nu8gpGnP1PBwYDqqiT7WfYP3h7Fx0G086+OczGaksZ5uj86XXJ6p6QwrDvsS9t69rpVK cTGA== 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=ltPfVwP6GVU9RSNfsZqjJzGVX5hEBz0phnPqK9oVdM0=; b=FLzL2s+MsA/1TOsJ7LFddyqlMEpZprk20Kps31v6zf6tK2pMQMlc8PrYl/nCs1+Em5 2GDlnBsxxXnRUG3Pkr6PeVUASsS1s2fzkMOB1sSTdBMPuYGk0HYum3HGFPcp2gTpneaD exoumFuQzy5VeKoyggBHZmxtBKBC3WRODZA5ZkKm4q2FtcDN/v87LmsiGbhI0xAdcdkJ 3ZFfqhW7i+O2RS9guX9XIgXi9mQ0DEknkaZLmOQYZs5aMxzqIFz1Xw2E9oHOVf6gPk6o ZASZZVLvTR9lYpZ740Pd9lUyD48fGdafeWxJjnJEMj2FHPzIc2mOCtyKV9wpqrR7NAlJ uazw== X-Gm-Message-State: AODbwcDalmXSonciMlIEUM5jIrwqTsv+y3y3fSllUuKWliWjAO1P4GWO BQsJmNtpAYKEicoaxB0M1XU2dr6Kvg== X-Received: by 10.202.192.67 with SMTP id q64mr13230551oif.65.1496685163256; Mon, 05 Jun 2017 10:52:43 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Mon, 5 Jun 2017 10:52:42 -0700 (PDT) In-Reply-To: <2619514e-7f54-bc62-02fc-d4f228fee121@eff.org> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <2a5e2bbf-5441-f647-bb98-6578376e69a7@eff.org> <2619514e-7f54-bc62-02fc-d4f228fee121@eff.org> From: Phillip Hallam-Baker Date: Mon, 5 Jun 2017 13:52:42 -0400 X-Google-Sender-Auth: FJU-1U3BI--Ac6mRkzwfywbwmfU Message-ID: To: Jacob Hoffman-Andrews Cc: SPASM , Rob Stradling Content-Type: multipart/alternative; boundary="001a1135b6c87f1f7a05513a2b86" Archived-At: Subject: Re: [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 17:52:45 -0000 --001a1135b6c87f1f7a05513a2b86 Content-Type: text/plain; charset="UTF-8" OK, will update and correct. Sorry about that. On Mon, Jun 5, 2017 at 12:56 PM, Jacob Hoffman-Andrews wrote: > When I visit https://www.rfc-editor.org/errata_search.php?eid=4992, > I still see this incorrect text: > > > If A(X) is not null, and CAA(A(X)), then R(X) = > > CAA(A(X)), otherwise > > Specifically the clause "and CAA(A(X))" should be "and CAA(A(X)) is not > empty". > > And yep, understandable about wanting to minimize changes to get this > through promptly; I'm fine with that. > --001a1135b6c87f1f7a05513a2b86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK,= will update and correct. Sorry about that.

On Mon, Jun 5, 2017 at 12:56 PM, Jaco= b Hoffman-Andrews <jsha@eff.org> wrote:
When I visit https://www.rfc-editor.= org/errata_search.php?eid=3D4992,
=C2=A0I still see this incorrect text:

> If A(X) is not null, and CAA(A(X)), then R(X) =3D
>=C2=A0 =C2=A0 =C2=A0 CAA(A(X)), otherwise

Specifically the clause "and CAA(A(X))" should be "an= d CAA(A(X)) is not
empty".

And yep, understandable about wanting to minimize changes to get this
through promptly; I'm fine with that.

--001a1135b6c87f1f7a05513a2b86-- From nobody Mon Jun 5 11:27: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 D18BB129BA4 for ; Mon, 5 Jun 2017 11:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 MibJSFMlKHke for ; Mon, 5 Jun 2017 11:27:11 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 679D9129BA3 for ; Mon, 5 Jun 2017 11:27:11 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id i31so1163170ota.3 for ; Mon, 05 Jun 2017 11:27:11 -0700 (PDT) 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=oElKQwfWNYhq8gX8wogLM5dwB2q6e5CySIR+KN9KsXQ=; b=b9SSOZoS3Le85bsi4Pf0BZH5pG/J49EYLDaohMFqeYT8h9HRy7yxoB8jeiIbV9hB+V Jsa8N8BacGw3TOhBCu/JJmiOGTUagCl7MMCBD8Og492SRdMKqdVj90plma7Mjcw/kL7X LI9PyIsitUbpZu9jD0QzKLSshdWM4OM33xYu9yYHIeY10fF/m0XITLTdUznk+UjMdGVH 8bxHMV9XC2UkUtkwzKqmXhPKF4Wyk9y6G3Be1VR8tVR42+smoj06nyQFjRnKdQqQN0qU UFFmphK9kOAJD5NX1/DF/2K5j6UEyqOku/W/Z55ZMwnpp9MM7vMdHrtkTPbRU8S9B1jI gdeg== 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=oElKQwfWNYhq8gX8wogLM5dwB2q6e5CySIR+KN9KsXQ=; b=FyNbEOwocxiyq7eC7RKdCYaJanyhjdQ895d9gpU8TO60o1lVdk3L2Hgnr5vlZPrlg9 90/qev+XWJBeVUalnXfalEF/U7XMnMcL/oF8K9Zvw/NSY+jNr+SJMPTmjUgrMKZ+h5Nj zkG6FWXZVPb+TFPRmEaK4yEfQAyIf4yxkuFiiu5ymR6eh4TYhGEt/3KP/1haf49xMB/Z lo9fmkze70950Lk3cuaQ/JXfIgyt0PyK16Gs4v4uCTZ8jhNW0xPimmNJbRoG09+wv/HJ j9eqdU4ab96hgDSBvzN1PQxtMVz0a3J4aTkm7Ly6k58bBmw12swsdmvHj6GgauYpAgM5 i6BA== X-Gm-Message-State: AODbwcBkw3PDX8i7t9+sY1asll7mMDvIJ+pLoZxWIDkxDQjVxXDmZ762 xvC0gfu9EyzAGTjKkVC+sLZk48Ug6Q== X-Received: by 10.157.0.73 with SMTP id 67mr9924580ota.112.1496687230722; Mon, 05 Jun 2017 11:27:10 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Mon, 5 Jun 2017 11:27:10 -0700 (PDT) In-Reply-To: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> From: Phillip Hallam-Baker Date: Mon, 5 Jun 2017 14:27:10 -0400 X-Google-Sender-Auth: YSeursOinjy2fNSvEsnCjzyxwCU Message-ID: To: Jacob Hoffman-Andrews Cc: SPASM , Rob Stradling Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 18:27:13 -0000 Thanks to Paul for also pointing this out. Is the following correct: Section 4 says: Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record specified at the label X. o If CAA(X) is not empty, R(X) = CAA (X), otherwise o If A(X) is not null, and R(A(X)) is not empty, then R(X) = R(A(X)), otherwise o If X is not a top-level domain, then R(X) = R(P(X)), otherwise o R(X) is empty. It should say: Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record chain specified at the label X. o If CAA(X) is not empty, R(X) = CAA (X), otherwise o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = CAA(A(X)), otherwise o If X is not a top-level domain, then R(X) = R(P(X)), otherwise o R(X) is empty. Thus, when a search at node X returns a CNAME record, the CA will follow the CNAME record to its target. If the target label contains a CAA record, it is returned. otherwise, the CA continues the search at the parent of node X. Note that the search does not include the parent of a target of a CNAME record (except when the CNAME points back to its own path). If the target of a CNAME record is itself a CNAME record, the CA MAY follow it or MAY ignore it. In either case, the search continues at the parent of the label containing the initial CNAME. Processing for DNAME is exactly the same as for CNAME. Note that since DNAME records are implemented by creating the corresponding CNAME records on the fly, it is only necessary for DNAME records to appear on the wire for purposes of DNSSEC. On Wed, Apr 5, 2017 at 3:43 PM, Jacob Hoffman-Andrews wrote: > https://www.rfc-editor.org/errata_search.php?eid=4988 > > Rob Stradling said: >> 2. Bug?: Shouldn't this... >> o If A(X) is not null, and CAA(A(X)), then R(X) = >> CAA(X), otherwise >> >> ...actually be this... >> >> o If A(X) is not null, and CAA(A(X)), then R(X) = >> CAA(A(X)), otherwise > > A further edit: "and CAA(A(X))" should be "and CAA(A(X)) is not empty" > > Also, did you see my earlier suggestion on the list? I think now that we > aren't tree-climbing on CNAME targets, we can express this algorithm in > a more straightforward way that emphasizes its similarity to how other > DNS records are looked up: > > ----- Proposal ----- > Let CAA(X) be the record set returned by performing a CAA record > query on the domain name X, according to the name server lookup > algorithm specified in RFC 1034 section 4.3.2 (in particular including > CNAME responses). Let P(X) be the domain name produced by removing the > leftmost label of X. > > - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise > - If P(X) is the root domain '.', then R(X) is empty, otherwise > - R(X) = R(P(X)) > > ----- End proposal ----- From nobody Mon Jun 5 15:04:16 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 220D612945E for ; Mon, 5 Jun 2017 15:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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_HI=-5, RP_MATCHES_RCVD=-0.001, 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=eff.org 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 8zdLXIIFtKBJ for ; Mon, 5 Jun 2017 15:04:12 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A6B12700F for ; Mon, 5 Jun 2017 15:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=sBkJkLlvpBV6jEImjg1lgOELr/BI229T79h3dhPrL6I=; b=Zn4b/cwWif/4YQh9DO7lPCBROVFFU1fvfWfb9LO5QB7qzguEW99qYNkp/XrPDKGld5Gg+bXEzjnzZE3GDGrdPMirUdbosRymbIwD5auzWif33BdWjc6bizZhh47HE3oLD/Kiv3JrbLqs5Yqb8xoU1/O46G0nq+hXQ+eBXPykJ6c=; Received: ; Mon, 05 Jun 2017 15:04:11 -0700 To: Phillip Hallam-Baker Cc: SPASM , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 5 Jun 2017 15:04:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jun 2017 22:04:15 -0000 This looks good to me, thanks! On 06/05/2017 11:27 AM, Phillip Hallam-Baker wrote: > Thanks to Paul for also pointing this out. Is the following correct: > > > Section 4 says: > > Let CAA(X) be the record set returned in response to performing a CAA > record query on the label X, P(X) be the DNS label immediately above > X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME > alias record specified at the label X. > > o If CAA(X) is not empty, R(X) = CAA (X), otherwise > > o If A(X) is not null, and R(A(X)) is not empty, then R(X) = > R(A(X)), otherwise > > o If X is not a top-level domain, then R(X) = R(P(X)), otherwise > > o R(X) is empty. > > > It should say: > > Let CAA(X) be the record set returned in response to performing a CAA > record query on the label X, P(X) be the DNS label immediately above > X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME > alias record chain specified at the label X. > > o If CAA(X) is not empty, R(X) = CAA (X), otherwise > > o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = > CAA(A(X)), otherwise > > o If X is not a top-level domain, then R(X) = R(P(X)), otherwise > > o R(X) is empty. > > Thus, when a search at node X returns a CNAME record, the CA will > follow the CNAME record to its target. If the target label contains a > CAA record, it is returned. otherwise, the CA continues the search at > the parent of node X. > > Note that the search does not include the parent of a target of a > CNAME record (except when the CNAME points back to its own path). > > If the target of a CNAME record is itself a CNAME record, the CA MAY > follow it or MAY ignore it. In either case, the search continues at > the parent of the label containing the initial CNAME. > > Processing for DNAME is exactly the same as for CNAME. Note that since > DNAME records are implemented by creating the corresponding CNAME > records on the fly, it is only necessary for DNAME records to appear > on the wire for purposes of DNSSEC. > > > > > > On Wed, Apr 5, 2017 at 3:43 PM, Jacob Hoffman-Andrews wrote: >> https://www.rfc-editor.org/errata_search.php?eid=4988 >> >> Rob Stradling said: >>> 2. Bug?: Shouldn't this... >>> o If A(X) is not null, and CAA(A(X)), then R(X) = >>> CAA(X), otherwise >>> >>> ...actually be this... >>> >>> o If A(X) is not null, and CAA(A(X)), then R(X) = >>> CAA(A(X)), otherwise >> A further edit: "and CAA(A(X))" should be "and CAA(A(X)) is not empty" >> >> Also, did you see my earlier suggestion on the list? I think now that we >> aren't tree-climbing on CNAME targets, we can express this algorithm in >> a more straightforward way that emphasizes its similarity to how other >> DNS records are looked up: >> >> ----- Proposal ----- >> Let CAA(X) be the record set returned by performing a CAA record >> query on the domain name X, according to the name server lookup >> algorithm specified in RFC 1034 section 4.3.2 (in particular including >> CNAME responses). Let P(X) be the domain name produced by removing the >> leftmost label of X. >> >> - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise >> - If P(X) is the root domain '.', then R(X) is empty, otherwise >> - R(X) = R(P(X)) >> >> ----- End proposal ----- From nobody Tue Jun 6 02:04:19 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 CB5AB1289C3 for ; Tue, 6 Jun 2017 02:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 n5lDQGMY39Li for ; Tue, 6 Jun 2017 02:04:14 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) (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 B08D0124217 for ; Tue, 6 Jun 2017 02:04:13 -0700 (PDT) Received: from Morten ([62.44.135.205]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id 2201706061104084941; Tue, 06 Jun 2017 11:04:08 +0200 From: "Erik Andersen" To: "LAMPS" Cc: "Paul Thorpe" , "Jean-Paul LEMAIRE" , "Carsten Strunge" Date: Tue, 6 Jun 2017 11:04:06 +0200 Message-ID: <003d01d2dea3$da70b260$8f521720$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01D2DEB4.9DFE3D50" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-gb Thread-Index: AdLelFWLfdCg3ipRTq+89qwH4HYbXg== Archived-At: Subject: [Spasm] ATTRIBUTE ASN.1 information object class X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Jun 2017 09:04:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003E_01D2DEB4.9DFE3D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit @ Jean-Paul and Paul, there is a question to you somewhere below. RFC 7030, Enrollment over Secure Transport (EST), have in section 4.2.1 a reference to an attribute type called ChangeSubjectName defined in RFC 6402. The EST specification is potentially going to be used in smart grid security. RFC 6402 defines this attribute type as: at-cmc-changeSubjectName ATTRIBUTE ::= { TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName } This looks very different from an "ordinary" attribute specifications. The ATTRIBUTE ASN.1 object class is imported from RFC 5912, where you will find ATTRIBUTE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL, &equality-match MATCHING-RULE OPTIONAL, &minCount INTEGER DEFAULT 1, &maxCount INTEGER OPTIONAL WITH SYNTAX { [TYPE &Type] [EQUALITY MATCHING RULE &equality-match] [COUNTS [MIN &minCount] [MAX &maxCount]] IDENTIFIED BY &id } This is a redefinition of the ATTRIBUTE information object class that has been defined in Rec. ITU-T X.501 | ISO/IEC 9594-2 since the stone age. This is in my opinion a NO-NO. It seems quite inappropriate in ITU-T recommendations and in International Standards, such a smart grid security standards, to reference any IETF attribute type specified using this modified information object class. We wold in some case have to import both ATTRIBUTE from RFC 5912 and from X.501 into the same module. This will not work. It will also cause confusion with IETF. EST references both the PKCS #9 attributes types (RFC 2985) specified using the X.501 information object class and the changeSubjectName specified using the modified information object class. It appears that in case where we need to reference an attribute type specified using the alternative ATTRIBUTE information object class, we have to redefine such attribute types using the X.501 information object class. Here comes the question to the ASN.1 guys: Can we do that without changing the object reference and the object identifier? Best regard, Erik ------=_NextPart_000_003E_01D2DEB4.9DFE3D50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

@ Jean-Paul and Paul, there is a question to you = somewhere below.

 

RFC 7030, = Enrollment over Secure Transport (EST), have in section 4.2.1 a = reference to an attribute type called ChangeSubjectName defined in RFC = 6402. The EST specification is potentially going to be used in smart = grid security.

 

RFC 6402 = defines this attribute type as:

 

at-cmc-changeSubjectName ATTRIBUTE = ::=3D     { TYPE ChangeSubjectName IDENTIFIED BY = id-cmc-changeSubjectName }

 

This looks = very different from an “ordinary” attribute specifications. = The ATTRIBUTE ASN.1 object class is imported from RFC 5912, where you = will find

 

ATTRIBUTE = ::=3D CLASS {

= &id        =      OBJECT IDENTIFIER = UNIQUE,

= &Type           = OPTIONAL,

&equality-match MATCHING-RULE = OPTIONAL,

= &minCount       INTEGER DEFAULT = 1,

= &maxCount       INTEGER OPTIONAL  =

WITH SYNTAX = {

[TYPE =           &Type]

[EQUALITY MATCHING RULE = &equality-match]

[COUNTS = [MIN &minCount] [MAX &maxCount]]

= IDENTIFIED BY &id  }

 

This is a = redefinition of the ATTRIBUTE information object class that has been = defined in Rec. ITU-T X.501 | ISO/IEC 9594-2 since the stone age. This = is in my opinion a NO-NO. It seems quite inappropriate in ITU-T = recommendations and in International Standards, such a smart grid = security standards, to reference any IETF attribute type specified using = this modified information object class. We wold in some case have to = import both ATTRIBUTE from RFC 5912 and from X.501 into the same module. = This will not work. It will also cause confusion with IETF. EST = references both the  PKCS #9 attributes types (RFC 2985) specified = using the X.501 information object class and the changeSubjectName = specified using the modified information object class.

 

It appears = that in case where we need to reference an attribute type specified = using the alternative ATTRIBUTE information object class, we have to = redefine such attribute types using the X.501 information object class. = Here comes the question to the ASN.1 guys: Can we do that without = changing the object reference and the object identifier? =   

 

Best regard,

 

Erik        &nb= sp;           &nbs= p;            = ;            =    =             &= nbsp;           &n= bsp;        =

------=_NextPart_000_003E_01D2DEB4.9DFE3D50-- From nobody Tue Jun 6 06:53:11 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 98366127867 for ; Tue, 6 Jun 2017 06:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 U5O_bhLU0yzt for ; Tue, 6 Jun 2017 06:53:06 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D85128AFE for ; Tue, 6 Jun 2017 06:53:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 33B2D300562 for ; Tue, 6 Jun 2017 09:53:05 -0400 (EDT) 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 42B8uuZTh18s for ; Tue, 6 Jun 2017 09:53:02 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2552330029C; Tue, 6 Jun 2017 09:53:02 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7FEA56B-EDBC-4ED5-9BF8-CBAABED1F2A9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 6 Jun 2017 09:53:01 -0400 In-Reply-To: <003d01d2dea3$da70b260$8f521720$@x500.eu> Cc: LAMPS , Carsten Strunge , Paul Thorpe , Jean-Paul LEMAIRE To: Erik Andersen References: <003d01d2dea3$da70b260$8f521720$@x500.eu> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] ATTRIBUTE ASN.1 information object class X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Jun 2017 13:53:09 -0000 --Apple-Mail=_C7FEA56B-EDBC-4ED5-9BF8-CBAABED1F2A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Erik: There was a huge change in the handling of Attribute between X.501-1989 = and X.501-1993. The syntax in RFC 5912 seems to use the modern ASN.1, = but the older Attribute semantics. Russ > On Jun 6, 2017, at 5:04 AM, Erik Andersen wrote: >=20 > @ Jean-Paul and Paul, there is a question to you somewhere below. > =20 > RFC 7030, Enrollment over Secure Transport (EST), have in section = 4.2.1 a reference to an attribute type called ChangeSubjectName defined = in RFC 6402. The EST specification is potentially going to be used in = smart grid security. > =20 > RFC 6402 defines this attribute type as: > =20 > at-cmc-changeSubjectName ATTRIBUTE ::=3D { TYPE ChangeSubjectName = IDENTIFIED BY id-cmc-changeSubjectName } > =20 > This looks very different from an =E2=80=9Cordinary=E2=80=9D attribute = specifications. The ATTRIBUTE ASN.1 object class is imported from RFC = 5912, where you will find=20 > =20 > ATTRIBUTE ::=3D CLASS { > &id OBJECT IDENTIFIER UNIQUE, > &Type OPTIONAL, > &equality-match MATCHING-RULE OPTIONAL, > &minCount INTEGER DEFAULT 1, > &maxCount INTEGER OPTIONAL =20 > WITH SYNTAX { > [TYPE &Type] > [EQUALITY MATCHING RULE &equality-match] > [COUNTS [MIN &minCount] [MAX &maxCount]] > IDENTIFIED BY &id } > =20 > This is a redefinition of the ATTRIBUTE information object class that = has been defined in Rec. ITU-T X.501 | ISO/IEC 9594-2 since the stone = age. This is in my opinion a NO-NO. It seems quite inappropriate in = ITU-T recommendations and in International Standards, such a smart grid = security standards, to reference any IETF attribute type specified using = this modified information object class. We wold in some case have to = import both ATTRIBUTE from RFC 5912 and from X.501 into the same module. = This will not work. It will also cause confusion with IETF. EST = references both the PKCS #9 attributes types (RFC 2985) specified using = the X.501 information object class and the changeSubjectName specified = using the modified information object class. > =20 > It appears that in case where we need to reference an attribute type = specified using the alternative ATTRIBUTE information object class, we = have to redefine such attribute types using the X.501 information object = class. Here comes the question to the ASN.1 guys: Can we do that without = changing the object reference and the object identifier? =20 > =20 > Best regard, > =20 > Erik = =20 --Apple-Mail=_C7FEA56B-EDBC-4ED5-9BF8-CBAABED1F2A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Erik:

There= was a huge change in the handling of Attribute between X.501-1989 and = X.501-1993.  The syntax in RFC 5912 seems to use the modern ASN.1, = but the older Attribute semantics.

Russ



On = Jun 6, 2017, at 5:04 AM, Erik Andersen <era@x500.eu> wrote:

@ Jean-Paul and Paul, there is a question to you somewhere = below.
 
RFC 7030, Enrollment over Secure Transport (EST), have in = section 4.2.1 a reference to an attribute type called ChangeSubjectName = defined in RFC 6402. The EST specification is potentially going to be = used in smart grid security.
 
RFC 6402 defines this attribute type = as:
 
at-cmc-changeSubjectName ATTRIBUTE = ::=3D     { TYPE ChangeSubjectName IDENTIFIED BY = id-cmc-changeSubjectName }
 
This looks very different from an = =E2=80=9Cordinary=E2=80=9D attribute specifications. The ATTRIBUTE ASN.1 = object class is imported from RFC 5912, where you will find 
 
ATTRIBUTE ::=3D CLASS {
&id        =      OBJECT IDENTIFIER UNIQUE,
&Type         =   OPTIONAL,
&equality-match MATCHING-RULE = OPTIONAL,
&minCount       INTEGER = DEFAULT 1,
&maxCount       INTEGER = OPTIONAL  
WITH SYNTAX {
[TYPE =           &Type]
[EQUALITY MATCHING RULE &equality-match]
[COUNTS [MIN &minCount] [MAX &maxCount]]
IDENTIFIED BY &id  }
 
This is a redefinition of the ATTRIBUTE = information object class that has been defined in Rec. ITU-T X.501 | = ISO/IEC 9594-2 since the stone age. This is in my opinion a NO-NO. It = seems quite inappropriate in ITU-T recommendations and in International = Standards, such a smart grid security standards, to reference any IETF = attribute type specified using this modified information object class. = We wold in some case have to import both ATTRIBUTE from RFC 5912 and = from X.501 into the same module. This will not work. It will also cause = confusion with IETF. EST references both the  PKCS #9 attributes = types (RFC 2985) specified using the X.501 information object class and = the changeSubjectName specified using the modified information object = class.
 
It appears that in case where we need to reference an = attribute type specified using the alternative ATTRIBUTE information = object class, we have to redefine such attribute types using the X.501 = information object class. Here comes the question to the ASN.1 = guys: Can = we do that without changing the object reference and the object = identifier?   
 
Best = regard,
 
Erik          = ;            &= nbsp;           &nb= sp;            = ; =             &n= bsp;           &nbs= p;        

= --Apple-Mail=_C7FEA56B-EDBC-4ED5-9BF8-CBAABED1F2A9-- From nobody Tue Jun 6 07:04:18 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 E3B09128DE7 for ; Tue, 6 Jun 2017 07:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 Cc0RbTJe5Q10 for ; Tue, 6 Jun 2017 07:04:14 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A086129479 for ; Tue, 6 Jun 2017 07:04:10 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id h4so178702757oib.3 for ; Tue, 06 Jun 2017 07:04:10 -0700 (PDT) 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=D0WqAEPvNiepRE/aEqvTOtjXOgZtLjeKfCxNQL7PqEs=; b=gsW0ej0SHQzDonh5BkujK3WPEVUUWO5JTWrlKfLK1nhFkHD5ePuAVnnWXE8X9e7/HD I5lCwcqVgoOKtNcK5RuSQa8ytneQ4lhl+J1igRxHrPXExcsaNyQuFTS89pocGNqhRU6f Io8xK7T4Twmy2J/5Mx9KsGlxvcOwOd8KzRRCMOKCljNOZmdB7MP7XXIIaBrVVmUEXp3Z NXl/D8dnfo+K48/Lq72MsA2ndYnKQQHqm2ypDDT2fklvLdsjA9xWSNtmzZy0KCyKEwFF fCdpA4LrEPjRnqhnxu4t0dUf9b2LWTlbC1AqgsKzxu8BYMSZKkTf2rQ9M56LUD6RZiOv 5bdA== 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=D0WqAEPvNiepRE/aEqvTOtjXOgZtLjeKfCxNQL7PqEs=; b=dqPRuNOX+aydNkFOzgJFuw5hKAFhC3193CMKb2UDo759I2yUgxiOhKutkLRpw+DXRS YVNjg+QzhkCIp1hYHeJVd06L4CsM8Pgg2gAli8BjPcPQ/Oj6KDvaZ+oWz6YZhpVI/OiJ Ux3rfXZvEKUyVS8W+MUKXAc654Yv02HT2NTwzTLCexVfN2cqBMuAyyEBThfB9TuaGVkg erhZzLq4IqVSZmhcTfTuHiG6SyKVn9IX9XSRrunrVp3RdoZBHdA2z3b/Gg/KuoiZnIlm RsXe7piQZ2Oo9E9nkV6HkfBl3pcK794GiRVGspI6CTNgLlZVCKyqhMn4fpw/6KDl4Zz5 lxhQ== X-Gm-Message-State: AODbwcCtD5TUNTPL9zzkogHOjiteJh7MBUkwN3L5f38hZvAssxi9Zpk9 iGKdAEvoSVdeJRMhKuaql3gSeg+5jg== X-Received: by 10.202.220.67 with SMTP id t64mr12574960oig.134.1496757849482; Tue, 06 Jun 2017 07:04:09 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Tue, 6 Jun 2017 07:04:08 -0700 (PDT) In-Reply-To: References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> From: Phillip Hallam-Baker Date: Tue, 6 Jun 2017 10:04:08 -0400 X-Google-Sender-Auth: th0DTEhVbHovvEf4wXsCQav3D2Q Message-ID: To: Jacob Hoffman-Andrews Cc: SPASM , Rob Stradling Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Jun 2017 14:04:17 -0000 It is now Errata 5029. https://www.rfc-editor.org/errata/eid5029 Looking for a CABForum seconder. On Mon, Jun 5, 2017 at 6:04 PM, Jacob Hoffman-Andrews wrote: > This looks good to me, thanks! > > On 06/05/2017 11:27 AM, Phillip Hallam-Baker wrote: >> Thanks to Paul for also pointing this out. Is the following correct: >> >> >> Section 4 says: >> >> Let CAA(X) be the record set returned in response to performing a CAA >> record query on the label X, P(X) be the DNS label immediately above >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> alias record specified at the label X. >> >> o If CAA(X) is not empty, R(X) = CAA (X), otherwise >> >> o If A(X) is not null, and R(A(X)) is not empty, then R(X) = >> R(A(X)), otherwise >> >> o If X is not a top-level domain, then R(X) = R(P(X)), otherwise >> >> o R(X) is empty. >> >> >> It should say: >> >> Let CAA(X) be the record set returned in response to performing a CAA >> record query on the label X, P(X) be the DNS label immediately above >> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME >> alias record chain specified at the label X. >> >> o If CAA(X) is not empty, R(X) = CAA (X), otherwise >> >> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = >> CAA(A(X)), otherwise >> >> o If X is not a top-level domain, then R(X) = R(P(X)), otherwise >> >> o R(X) is empty. >> >> Thus, when a search at node X returns a CNAME record, the CA will >> follow the CNAME record to its target. If the target label contains a >> CAA record, it is returned. otherwise, the CA continues the search at >> the parent of node X. >> >> Note that the search does not include the parent of a target of a >> CNAME record (except when the CNAME points back to its own path). >> >> If the target of a CNAME record is itself a CNAME record, the CA MAY >> follow it or MAY ignore it. In either case, the search continues at >> the parent of the label containing the initial CNAME. >> >> Processing for DNAME is exactly the same as for CNAME. Note that since >> DNAME records are implemented by creating the corresponding CNAME >> records on the fly, it is only necessary for DNAME records to appear >> on the wire for purposes of DNSSEC. >> >> >> >> >> >> On Wed, Apr 5, 2017 at 3:43 PM, Jacob Hoffman-Andrews wrote: >>> https://www.rfc-editor.org/errata_search.php?eid=4988 >>> >>> Rob Stradling said: >>>> 2. Bug?: Shouldn't this... >>>> o If A(X) is not null, and CAA(A(X)), then R(X) = >>>> CAA(X), otherwise >>>> >>>> ...actually be this... >>>> >>>> o If A(X) is not null, and CAA(A(X)), then R(X) = >>>> CAA(A(X)), otherwise >>> A further edit: "and CAA(A(X))" should be "and CAA(A(X)) is not empty" >>> >>> Also, did you see my earlier suggestion on the list? I think now that we >>> aren't tree-climbing on CNAME targets, we can express this algorithm in >>> a more straightforward way that emphasizes its similarity to how other >>> DNS records are looked up: >>> >>> ----- Proposal ----- >>> Let CAA(X) be the record set returned by performing a CAA record >>> query on the domain name X, according to the name server lookup >>> algorithm specified in RFC 1034 section 4.3.2 (in particular including >>> CNAME responses). Let P(X) be the domain name produced by removing the >>> leftmost label of X. >>> >>> - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise >>> - If P(X) is the root domain '.', then R(X) is empty, otherwise >>> - R(X) = R(P(X)) >>> >>> ----- End proposal ----- > From nobody Tue Jun 6 07:42: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 36DAA12946A for ; Tue, 6 Jun 2017 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 pxM9RpzzodjW for ; Tue, 6 Jun 2017 07:42:13 -0700 (PDT) Received: from fortress.oss.com (fortress.oss.com [98.112.73.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB0112944C for ; Tue, 6 Jun 2017 07:42:13 -0700 (PDT) Received: from Graybox (localhost [127.0.0.1]) by fortress.oss.com (8.15.1+Sun/8.15.1) with ESMTP id v56Eg8wZ028355; Tue, 6 Jun 2017 07:42:08 -0700 (PDT) Date: Tue, 6 Jun 2017 07:42:07 -0700 (Pacific Daylight Time) From: Paul Thorpe To: Erik Andersen cc: LAMPS , Jean-Paul LEMAIRE , Carsten Strunge In-Reply-To: <003d01d2dea3$da70b260$8f521720$@x500.eu> Message-ID: References: <003d01d2dea3$da70b260$8f521720$@x500.eu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: thorpe@[127.0.0.1] MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2304176-15153-1496760128=:1060" Archived-At: Subject: Re: [Spasm] ATTRIBUTE ASN.1 information object class X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Jun 2017 14:42:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2304176-15153-1496760128=:1060 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi Erik, Jean-Paul gave a similar answer to what I had in mind when I saw your message. You could import both definitions of ATTRIBUTE, but would need to prefix them with the module name from which they came when you referenced them to indicate which one you are referring to. ---------------------------------------------------------------------------- Paul E. Thorpe Toll Free : 1-888-OSS-ASN1 OSS Nokalva International: 1-732-302-0750 Email: thorpe@oss.com Tech Support : 1-732-302-9669 http://www.oss.com Fax : 1-732-302-0023 On Tue, 6 Jun 2017, Erik Andersen wrote: > > @ Jean-Paul and Paul, there is a question to you somewhere below. > > > > RFC 7030, Enrollment over Secure Transport (EST), have in section 4.2.1 a reference to an attribute type > called ChangeSubjectName defined in RFC 6402. The EST specification is potentially going to be used in > smart grid security. > > > > RFC 6402 defines this attribute type as: > > > > at-cmc-changeSubjectName ATTRIBUTE ::=     { TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName > } > > > > This looks very different from an “ordinary” attribute specifications. The ATTRIBUTE ASN.1 object class is > imported from RFC 5912, where you will find > > > > ATTRIBUTE ::= CLASS { > > &id             OBJECT IDENTIFIER UNIQUE, > > &Type           OPTIONAL, > > &equality-match MATCHING-RULE OPTIONAL, > > &minCount       INTEGER DEFAULT 1, > > &maxCount       INTEGER OPTIONAL > > WITH SYNTAX { > > [TYPE           &Type] > > [EQUALITY MATCHING RULE &equality-match] > > [COUNTS [MIN &minCount] [MAX &maxCount]] > > IDENTIFIED BY &id  } > > > > This is a redefinition of the ATTRIBUTE information object class that has been defined in Rec. ITU-T X.501 > | ISO/IEC 9594-2 since the stone age. This is in my opinion a NO-NO. It seems quite inappropriate in ITU-T > recommendations and in International Standards, such a smart grid security standards, to reference any IETF > attribute type specified using this modified information object class. We wold in some case have to import > both ATTRIBUTE from RFC 5912 and from X.501 into the same module. This will not work. It will also cause > confusion with IETF. EST references both the  PKCS #9 attributes types (RFC 2985) specified using the X.501 > information object class and the changeSubjectName specified using the modified information object class. > > > > It appears that in case where we need to reference an attribute type specified using the alternative > ATTRIBUTE information object class, we have to redefine such attribute types using the X.501 information > object class. Here comes the question to the ASN.1 guys: Can we do that without changing the object > reference and the object identifier? > > > > Best regard, > > > > Erik > > > --2304176-15153-1496760128=:1060-- From nobody Tue Jun 6 07:50:47 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 F0E3C129510 for ; Tue, 6 Jun 2017 07:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 HqUe3RpQ3jgH for ; Tue, 6 Jun 2017 07:50:42 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (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 ECAE4129482 for ; Tue, 6 Jun 2017 07:50:40 -0700 (PDT) Received: from Morten ([62.44.135.205]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201706061650356688; Tue, 06 Jun 2017 16:50:35 +0200 From: "Erik Andersen" To: "'Russ Housley'" Cc: "'LAMPS'" , "'Carsten Strunge'" , "'Paul Thorpe'" , "'Jean-Paul LEMAIRE'" References: <003d01d2dea3$da70b260$8f521720$@x500.eu> In-Reply-To: Date: Tue, 6 Jun 2017 16:50:35 +0200 Message-ID: <000001d2ded4$4187d660$c4978320$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D2DEE5.0512F050" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHSx24TPZ934buoZGrCvtTbyHvoVAF5pX7UogxH8zA= Content-Language: en-gb Archived-At: Subject: Re: [Spasm] ATTRIBUTE ASN.1 information object class X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Jun 2017 14:50:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D2DEE5.0512F050 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Russ, =20 Yes, it is true that the first edition of X.501 used the terrible ASN.1 = macro notation and that the ATTRIBUTE specification was changed to using = ASN.1 information object class in the 1993 edition. So the current = ATTRIBUTE notation has been around maybe not from the stone age, but = since 1993. The syntax in RFC 5912 is quite different from the one that = has been in X.501 since 1993. The syntax in RFC 5912 is not the same as = the modern ASN.1 from X.501. I acknowledge that semantics is almost the = same and that the bits on the line are the same. =20 Erik Fra: Russ Housley [mailto:housley@vigilsec.com]=20 Sendt: 06 June 2017 15:53 Til: Erik Andersen Cc: LAMPS ; Carsten Strunge ; Paul = Thorpe ; Jean-Paul LEMAIRE = Emne: Re: [Spasm] ATTRIBUTE ASN.1 information object class =20 Erik: =20 There was a huge change in the handling of Attribute between X.501-1989 = and X.501-1993. The syntax in RFC 5912 seems to use the modern ASN.1, = but the older Attribute semantics. =20 Russ =20 =20 =20 On Jun 6, 2017, at 5:04 AM, Erik Andersen > wrote: =20 @ Jean-Paul and Paul, there is a question to you somewhere below. =20 RFC 7030, Enrollment over Secure Transport (EST), have in section 4.2.1 = a reference to an attribute type called ChangeSubjectName defined in RFC = 6402. The EST specification is potentially going to be used in smart = grid security. =20 RFC 6402 defines this attribute type as: =20 at-cmc-changeSubjectName ATTRIBUTE ::=3D { TYPE ChangeSubjectName = IDENTIFIED BY id-cmc-changeSubjectName } =20 This looks very different from an =E2=80=9Cordinary=E2=80=9D attribute = specifications. The ATTRIBUTE ASN.1 object class is imported from RFC = 5912, where you will find=20 =20 ATTRIBUTE ::=3D CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL, &equality-match MATCHING-RULE OPTIONAL, &minCount INTEGER DEFAULT 1, &maxCount INTEGER OPTIONAL =20 WITH SYNTAX { [TYPE &Type] [EQUALITY MATCHING RULE &equality-match] [COUNTS [MIN &minCount] [MAX &maxCount]] IDENTIFIED BY &id } =20 This is a redefinition of the ATTRIBUTE information object class that = has been defined in Rec. ITU-T X.501 | ISO/IEC 9594-2 since the stone = age. This is in my opinion a NO-NO. It seems quite inappropriate in = ITU-T recommendations and in International Standards, such a smart grid = security standards, to reference any IETF attribute type specified using = this modified information object class. We wold in some case have to = import both ATTRIBUTE from RFC 5912 and from X.501 into the same module. = This will not work. It will also cause confusion with IETF. EST = references both the PKCS #9 attributes types (RFC 2985) specified using = the X.501 information object class and the changeSubjectName specified = using the modified information object class. =20 It appears that in case where we need to reference an attribute type = specified using the alternative ATTRIBUTE information object class, we = have to redefine such attribute types using the X.501 information object = class. Here comes the question to the ASN.1 guys: Can we do that without = changing the object reference and the object identifier? =20 =20 Best regard, =20 Erik = =20 =20 ------=_NextPart_000_0001_01D2DEE5.0512F050 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Russ,

 

Yes, it is true that the first edition of = X.501 used the terrible ASN.1 macro notation and that the ATTRIBUTE = specification was changed to using ASN.1 information object class in the = 1993 edition. So the current ATTRIBUTE notation has been around maybe = not from the stone age, but since 1993. The syntax in RFC 5912 is quite = different from the one that has been in X.501 since 1993. =C2=A0The = syntax in RFC 5912 is not the same as the modern ASN.1 from X.501. = =C2=A0I acknowledge that semantics is almost the same and that the bits = on the line are the same.

 

Erik

Fra: = Russ Housley [mailto:housley@vigilsec.com]
Sendt: 06 June = 2017 15:53
Til: Erik Andersen = <era@x500.eu>
Cc: LAMPS <spasm@ietf.org>; Carsten = Strunge <CAS@energinet.dk>; Paul Thorpe <thorpe@oss.com>; = Jean-Paul LEMAIRE = <jean-paul.lemaire@univ-paris-diderot.fr>
Emne: Re: = [Spasm] ATTRIBUTE ASN.1 information object = class

 

Erik:

 

There was a huge change in the handling of Attribute = between X.501-1989 and X.501-1993.  The syntax in RFC 5912 seems to = use the modern ASN.1, but the older Attribute = semantics.

 

Russ

 

 

 

On Jun 6, 2017, at 5:04 AM, Erik Andersen <era@x500.eu> = wrote:

 

@ Jean-Paul = and Paul, there is a question to you somewhere = below.

 

RFC 7030, = Enrollment over Secure Transport (EST), have in section 4.2.1 a = reference to an attribute type called ChangeSubjectName defined in RFC = 6402. The EST specification is potentially going to be used in smart = grid security.

 

RFC 6402 = defines this attribute type as:

 

at-cmc-change= SubjectName ATTRIBUTE ::=3D     { TYPE = ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName = }

 

This looks = very different from an =E2=80=9Cordinary=E2=80=9D attribute = specifications. The ATTRIBUTE ASN.1 object class is imported from RFC = 5912, where you will find 

 

ATTRIBUTE ::=3D = CLASS {

&id        =      OBJECT IDENTIFIER UNIQUE,

&Type         &nbs= p; OPTIONAL,

&equality-match = MATCHING-RULE OPTIONAL,

&minCount       INTEGER DEFAULT = 1,

&maxCount       INTEGER = OPTIONAL  

WITH SYNTAX = {

[TYPE =           &Type]

[EQUALITY MATCHING = RULE &equality-match]

[COUNTS [MIN = &minCount] [MAX &maxCount]]

IDENTIFIED BY = &id  }

 

This is a = redefinition of the ATTRIBUTE information object class that has been = defined in Rec. ITU-T X.501 | ISO/IEC 9594-2 since the stone age. This = is in my opinion a NO-NO. It seems quite inappropriate in ITU-T = recommendations and in International Standards, such a smart grid = security standards, to reference any IETF attribute type specified using = this modified information object class. We wold in some case have to = import both ATTRIBUTE from RFC 5912 and from X.501 into the same module. = This will not work. It will also cause confusion with IETF. EST = references both the  PKCS #9 attributes types (RFC 2985) specified = using the X.501 information object class and the changeSubjectName = specified using the modified information object = class.

 

It appears = that in case where we need to reference an attribute type specified = using the alternative ATTRIBUTE information object class, we have to = redefine such attribute types using the X.501 information object class. = Here comes the question to the ASN.1 guys: Can we do that without = changing the object reference and the object identifier?   =

 

Best = regard,

 

Erik &nb= sp;           &nbs= p;            = ;            =           =             &= nbsp;           &n= bsp;        

 

------=_NextPart_000_0001_01D2DEE5.0512F050-- From nobody Tue Jun 6 08:59:47 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 7F68D12940C for ; Tue, 6 Jun 2017 08:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 XXw25Q8_zrSN for ; Tue, 6 Jun 2017 08:59:41 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 5DFD61296CF for ; Tue, 6 Jun 2017 08:59:41 -0700 (PDT) Received: from Morten ([62.44.135.205]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201706061759359244; Tue, 06 Jun 2017 17:59:35 +0200 From: "Erik Andersen" To: "'Paul Thorpe'" Cc: "'LAMPS'" , "'Carsten Strunge'" , "'Jean-Paul LEMAIRE'" References: <003d01d2dea3$da70b260$8f521720$@x500.eu> In-Reply-To: Date: Tue, 6 Jun 2017 17:59:35 +0200 Message-ID: <001501d2dedd$e537be20$afa73a60$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHSx24TPZ934buoZGrCvtTbyHvoVAGr7an6ogrBldA= Content-Language: en-gb Archived-At: Subject: Re: [lamps] [Spasm] ATTRIBUTE ASN.1 information object class X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Jun 2017 15:59:44 -0000 Hi Paul, Thanks for your comment. I was not aware that we could prefix with = module name. However, doing this makes our specification unnecessary = messy and more difficult to understand. There will be a need for some = rather complicated notes to explain why we are using two different = notations for the same thing. Do you agree with Jean-Paul that it from an ASN.1 point of view would be = legal to redefine RFC 5912 attribute types using the same object name = and object identifier or should we define completely new replacement = attribute types. We will run into the same issue when defining the CMS = profile. Will the following be legal? Changing at-cmc-changeSubjectName ATTRIBUTE ::=3D {=20 TYPE ChangeSubjectName=20 IDENTIFIED BY id-cmc-changeSubjectName } to at-cmc-changeSubjectName ATTRIBUTE ::=3D { SYNTAX ChangeSubjectName=20 ID id-cmc-changeSubjectName } Kind regards, Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Paul Thorpe Sendt: 06 June 2017 16:42 Til: Erik Andersen Cc: LAMPS ; Carsten Strunge ; = Jean-Paul LEMAIRE Emne: Re: [Spasm] ATTRIBUTE ASN.1 information object class Hi Erik, Jean-Paul gave a similar answer to what I had in mind when I saw your = message. You could import both definitions of ATTRIBUTE, but would need = to prefix them with the module name from which they came when you = referenced them to indicate which one you are referring to. -------------------------------------------------------------------------= --- Paul E. Thorpe Toll Free : = 1-888-OSS-ASN1 OSS Nokalva International: = 1-732-302-0750 Email: thorpe@oss.com Tech Support : = 1-732-302-9669 http://www.oss.com Fax : = 1-732-302-0023 On Tue, 6 Jun 2017, Erik Andersen wrote: >=20 > @ Jean-Paul and Paul, there is a question to you somewhere below. > >=20 >=20 > RFC 7030, Enrollment over Secure Transport (EST), have in section=20 > 4.2.1 a reference to an attribute type called ChangeSubjectName=20 > defined in RFC 6402. The EST specification is potentially going to be = used in smart grid security. > >=20 >=20 > RFC 6402 defines this attribute type as: > >=20 >=20 > at-cmc-changeSubjectName ATTRIBUTE ::=3D { TYPE ChangeSubjectName=20 > IDENTIFIED BY id-cmc-changeSubjectName } > >=20 >=20 > This looks very different from an =E2=80=9Cordinary=E2=80=9D attribute = specifications.=20 > The ATTRIBUTE ASN.1 object class is imported from RFC 5912, where you=20 > will find > >=20 >=20 > ATTRIBUTE ::=3D CLASS { >=20 > &id OBJECT IDENTIFIER UNIQUE, >=20 > &Type OPTIONAL, >=20 > &equality-match MATCHING-RULE OPTIONAL, >=20 > &minCount INTEGER DEFAULT 1, >=20 > &maxCount INTEGER OPTIONAL >=20 > WITH SYNTAX { >=20 > [TYPE &Type] >=20 > [EQUALITY MATCHING RULE &equality-match] >=20 > [COUNTS [MIN &minCount] [MAX &maxCount]] >=20 > IDENTIFIED BY &id } > >=20 >=20 > This is a redefinition of the ATTRIBUTE information object class that=20 > has been defined in Rec. ITU-T X.501 > | ISO/IEC 9594-2 since the stone age. This is in my opinion a NO-NO.=20 > | It seems quite inappropriate in ITU-T > recommendations and in International Standards, such a smart grid=20 > security standards, to reference any IETF attribute type specified=20 > using this modified information object class. We wold in some case=20 > have to import both ATTRIBUTE from RFC 5912 and from X.501 into the=20 > same module. This will not work. It will also cause confusion with = IETF. EST references both the PKCS #9 attributes types (RFC 2985) = specified using the X.501 information object class and the = changeSubjectName specified using the modified information object class. > >=20 >=20 > It appears that in case where we need to reference an attribute type=20 > specified using the alternative ATTRIBUTE information object class, we = > have to redefine such attribute types using the X.501 information=20 > object class. Here comes the question to the ASN.1 guys: Can we do = that without changing the object reference and the object identifier? > >=20 >=20 > Best regard, > >=20 >=20 > Erik >=20 >=20 > From nobody Tue Jun 6 09:10:42 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 2D8BE129496 for ; Tue, 6 Jun 2017 09:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ljXdWXdZNT3T for ; Tue, 6 Jun 2017 09:10:37 -0700 (PDT) Received: from fortress.oss.com (fortress.oss.com [98.112.73.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C105F12947B for ; Tue, 6 Jun 2017 09:10:37 -0700 (PDT) Received: from Graybox (localhost [127.0.0.1]) by fortress.oss.com (8.15.1+Sun/8.15.1) with ESMTP id v56GAXNf007443; Tue, 6 Jun 2017 09:10:33 -0700 (PDT) Date: Tue, 6 Jun 2017 09:10:32 -0700 (Pacific Daylight Time) From: Paul Thorpe To: Erik Andersen cc: "'LAMPS'" , "'Carsten Strunge'" , "'Jean-Paul LEMAIRE'" In-Reply-To: <001501d2dedd$e537be20$afa73a60$@x500.eu> Message-ID: References: <003d01d2dea3$da70b260$8f521720$@x500.eu> <001501d2dedd$e537be20$afa73a60$@x500.eu> User-Agent: Alpine 2.20 (WNT 67 2015-01-07) X-X-Sender: thorpe@[127.0.0.1] MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="334050-29688-1496765115=:19400" Content-ID: Archived-At: Subject: Re: [lamps] [Spasm] ATTRIBUTE ASN.1 information object class X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Jun 2017 16:10:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --334050-29688-1496765115=:19400 Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hi Erik, I see no problem with that kind of change as long as the class definition components are compatible. The "TYPE", "IDENTIFIED BY", "SYNTAX" and "ID" are not critical to the definitions. Changing those words does not alter the underlying class definition. They potentially make it easier for a human reader to understand the object definitions while writing them. ---------------------------------------------------------------------------- Paul E. Thorpe Toll Free : 1-888-OSS-ASN1 OSS Nokalva International: 1-732-302-0750 Email: thorpe@oss.com Tech Support : 1-732-302-9669 http://www.oss.com Fax : 1-732-302-0023 On Tue, 6 Jun 2017, Erik Andersen wrote: > Hi Paul, > > Thanks for your comment. I was not aware that we could prefix with module name. However, doing this makes our specification unnecessary messy and more difficult to understand. There will be a need for some rather complicated notes to explain why we are using two different notations for the same thing. > > Do you agree with Jean-Paul that it from an ASN.1 point of view would be legal to redefine RFC 5912 attribute types using the same object name and object identifier or should we define completely new replacement attribute types. We will run into the same issue when defining the CMS profile. > > Will the following be legal? > > Changing > > at-cmc-changeSubjectName ATTRIBUTE ::= { > TYPE ChangeSubjectName > IDENTIFIED BY id-cmc-changeSubjectName } > > to > > at-cmc-changeSubjectName ATTRIBUTE ::= { > SYNTAX ChangeSubjectName > ID id-cmc-changeSubjectName } > > Kind regards, > > Erik > > -----Oprindelig meddelelse----- > Fra: Spasm [mailto:spasm-bounces@ietf.org] På vegne af Paul Thorpe > Sendt: 06 June 2017 16:42 > Til: Erik Andersen > Cc: LAMPS ; Carsten Strunge ; Jean-Paul LEMAIRE > Emne: Re: [Spasm] ATTRIBUTE ASN.1 information object class > > Hi Erik, > > Jean-Paul gave a similar answer to what I had in mind when I saw your message. You could import both definitions of ATTRIBUTE, but would need to prefix them with the module name from which they came when you referenced them to indicate which one you are referring to. > > ---------------------------------------------------------------------------- > Paul E. Thorpe Toll Free : 1-888-OSS-ASN1 > OSS Nokalva International: 1-732-302-0750 > Email: thorpe@oss.com Tech Support : 1-732-302-9669 > http://www.oss.com Fax : 1-732-302-0023 > > On Tue, 6 Jun 2017, Erik Andersen wrote: > >> >> @ Jean-Paul and Paul, there is a question to you somewhere below. >> >> >> >> RFC 7030, Enrollment over Secure Transport (EST), have in section >> 4.2.1 a reference to an attribute type called ChangeSubjectName >> defined in RFC 6402. The EST specification is potentially going to be used in smart grid security. >> >> >> >> RFC 6402 defines this attribute type as: >> >> >> >> at-cmc-changeSubjectName ATTRIBUTE ::= { TYPE ChangeSubjectName >> IDENTIFIED BY id-cmc-changeSubjectName } >> >> >> >> This looks very different from an “ordinary” attribute specifications. >> The ATTRIBUTE ASN.1 object class is imported from RFC 5912, where you >> will find >> >> >> >> ATTRIBUTE ::= CLASS { >> >> &id OBJECT IDENTIFIER UNIQUE, >> >> &Type OPTIONAL, >> >> &equality-match MATCHING-RULE OPTIONAL, >> >> &minCount INTEGER DEFAULT 1, >> >> &maxCount INTEGER OPTIONAL >> >> WITH SYNTAX { >> >> [TYPE &Type] >> >> [EQUALITY MATCHING RULE &equality-match] >> >> [COUNTS [MIN &minCount] [MAX &maxCount]] >> >> IDENTIFIED BY &id } >> >> >> >> This is a redefinition of the ATTRIBUTE information object class that >> has been defined in Rec. ITU-T X.501 >> | ISO/IEC 9594-2 since the stone age. This is in my opinion a NO-NO. >> | It seems quite inappropriate in ITU-T >> recommendations and in International Standards, such a smart grid >> security standards, to reference any IETF attribute type specified >> using this modified information object class. We wold in some case >> have to import both ATTRIBUTE from RFC 5912 and from X.501 into the >> same module. This will not work. It will also cause confusion with IETF. EST references both the PKCS #9 attributes types (RFC 2985) specified using the X.501 information object class and the changeSubjectName specified using the modified information object class. >> >> >> >> It appears that in case where we need to reference an attribute type >> specified using the alternative ATTRIBUTE information object class, we >> have to redefine such attribute types using the X.501 information >> object class. Here comes the question to the ASN.1 guys: Can we do that without changing the object reference and the object identifier? >> >> >> >> Best regard, >> >> >> >> Erik >> >> >> > > > --334050-29688-1496765115=:19400-- From nobody Tue Jun 6 09:24: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 D351B129498 for ; Tue, 6 Jun 2017 09:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.org 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 jIxhtzbdGFi4 for ; Tue, 6 Jun 2017 09:24:08 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FF712947E for ; Tue, 6 Jun 2017 09:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:Subject:From; bh=2rLxHQv57RYfpsDmBp073AlHO+/z4sq2Id5bC4qq/7E=; b=q6zbMeS+28m2Egdn+D+8EcLaf5HJR4zeBZyh4GxljIhSBoBWfQgfb0DJ6YtA2OZ3cUFaNyslzr/KGsfLa7uNPUnDoVKws9YEplybeb7FMXDjvFex8LoOljXZefc5vkxqiKnWf9tPbYs+3/ggPY9JXmPY2PKqCndu+AzV0pgrl4Y=; Received: ; Tue, 06 Jun 2017 09:24:06 -0700 From: Jacob Hoffman-Andrews To: Phillip Hallam-Baker Cc: SPASM , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> Message-ID: Date: Tue, 6 Jun 2017 09:24:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------328989437D5E3E3A0641F125" Content-Language: en-US Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Jun 2017 16:24:11 -0000 This is a multi-part message in MIME format. --------------328989437D5E3E3A0641F125 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Great! I was giving a final read-through and noticed a couple more problems. Sorry I didn't spot these on the first read: > Note that the search does not include the parent of a target of a > CNAME record (except when the CNAME points back to its own path). It's not clear what "back to its own path" means here. How about "unless it happens to be the result of one of the P(X) lookups in the algorithm above" > If the target of a CNAME record is itself a CNAME record, the CA MAY > follow it or MAY ignore it. In either case, the search continues at > the parent of the label containing the initial CNAME. This seems to introduce a normative statement that CAs need only chase CNAME alias record chains one level deep, when the rest of DNS assumes that you will chase them arbitrarily deep, with loops treated as an error= : RFC 1034 3.6.1: > CNAME chains should be followed and CNAME loops signalled as an error. It's undesirable to introduce these two MAYs because they creates ambiguity in how different CAs will interpret a given CAA configuration containing chained CNAMEs. I think we should remove the paragraph starting with "If the target of a CNAME record..." On 06/06/2017 07:04 AM, Phillip Hallam-Baker wrote: > It is now Errata 5029. > > https://www.rfc-editor.org/errata/eid5029 > > Looking for a CABForum seconder. > > On Mon, Jun 5, 2017 at 6:04 PM, Jacob Hoffman-Andrews wr= ote: >> This looks good to me, thanks! >> >> On 06/05/2017 11:27 AM, Phillip Hallam-Baker wrote: >>> Thanks to Paul for also pointing this out. Is the following correct: >>> >>> >>> Section 4 says: >>> >>> Let CAA(X) be the record set returned in response to performing a = CAA >>> record query on the label X, P(X) be the DNS label immediately abo= ve >>> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME= >>> alias record specified at the label X. >>> >>> o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >>> >>> o If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D >>> R(A(X)), otherwise >>> >>> o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwis= e >>> >>> o R(X) is empty. >>> >>> >>> It should say: >>> >>> Let CAA(X) be the record set returned in response to performing a = CAA >>> record query on the label X, P(X) be the DNS label immediately abo= ve >>> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME= >>> alias record chain specified at the label X. >>> >>> o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise >>> >>> o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D >>> CAA(A(X)), otherwise >>> >>> o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwis= e >>> >>> o R(X) is empty. >>> >>> Thus, when a search at node X returns a CNAME record, the CA will >>> follow the CNAME record to its target. If the target label contains= a >>> CAA record, it is returned. otherwise, the CA continues the search = at >>> the parent of node X. >>> >>> Note that the search does not include the parent of a target of a >>> CNAME record (except when the CNAME points back to its own path). >>> >>> If the target of a CNAME record is itself a CNAME record, the CA MA= Y >>> follow it or MAY ignore it. In either case, the search continues at= >>> the parent of the label containing the initial CNAME. >>> >>> Processing for DNAME is exactly the same as for CNAME. Note that si= nce >>> DNAME records are implemented by creating the corresponding CNAME >>> records on the fly, it is only necessary for DNAME records to appea= r >>> on the wire for purposes of DNSSEC. >>> >>> >>> >>> >>> >>> On Wed, Apr 5, 2017 at 3:43 PM, Jacob Hoffman-Andrews = wrote: >>>> https://www.rfc-editor.org/errata_search.php?eid=3D4988 >>>> >>>> Rob Stradling said: >>>>> 2. Bug?: Shouldn't this... >>>>> o If A(X) is not null, and CAA(A(X)), then R(X) =3D >>>>> CAA(X), otherwise >>>>> >>>>> ...actually be this... >>>>> >>>>> o If A(X) is not null, and CAA(A(X)), then R(X) =3D >>>>> CAA(A(X)), otherwise >>>> A further edit: "and CAA(A(X))" should be "and CAA(A(X)) is not empt= y" >>>> >>>> Also, did you see my earlier suggestion on the list? I think now tha= t we >>>> aren't tree-climbing on CNAME targets, we can express this algorithm= in >>>> a more straightforward way that emphasizes its similarity to how oth= er >>>> DNS records are looked up: >>>> >>>> ----- Proposal ----- >>>> Let CAA(X) be the record set returned by performing a CAA record >>>> query on the domain name X, according to the name server lookup >>>> algorithm specified in RFC 1034 section 4.3.2 (in particular includi= ng >>>> CNAME responses). Let P(X) be the domain name produced by removing t= he >>>> leftmost label of X. >>>> >>>> - If CAA(X) contains any CAA resource records, R(X) =3D CAA(X), oth= erwise >>>> - If P(X) is the root domain '.', then R(X) is empty, otherwise >>>> - R(X) =3D R(P(X)) >>>> >>>> ----- End proposal ----- > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --------------328989437D5E3E3A0641F125 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Great! I was giving a final read-through and noticed a couple more problems. Sorry I didn't spot these on the first read:

>  Note that the search does not include the parent of a target of a
>  CNAME record (except when the CNAME points back to its own path).

It's not clear what "back to its own path" means here. How about "unless it happens to be the result of one of the P(X) lookups in the algorithm above"

>  If the target of a CNAME record is itself a CNAME record, the CA MAY
>  follow it or MAY ignore it. In either case, the search continues at
>  the parent of the label containing the initial CNAME.

This seems to introduce a normative statement that CAs need only chase CNAME alias record chains one level deep, when the rest of DNS assumes that you will chase them arbitrarily deep, with loops treated as an error:

RFC 1034 3.6.1:
> CNAME chains should be followed and CNAME loops signalled as an error.

It's undesirable to introduce these two MAYs because they creates ambiguity in how different CAs will interpret a given CAA configuration containing chained CNAMEs.

I think we should remove the paragraph starting with "If the target of a CNAME record..."

On 06/06/2017 07:04 AM, Phillip Hallam-Baker wrote:
It is now Errata 5029.

https://www.rfc-editor.org/errata/eid5029

Looking for a CABForum seconder.

On Mon, Jun 5, 2017 at 6:04 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:

This looks good to me, thanks!

On 06/05/2017 11:27 AM, Phillip Hallam-Baker wrote:

Thanks to Paul for also pointing this out. Is the following correct:


Section 4 says:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.


It should say:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record chain specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

  Thus, when a search at node X returns a CNAME record, the CA will
  follow the CNAME record to its target. If the target label contains a
  CAA record, it is returned. otherwise, the CA continues the search at
  the parent of node X.

  Note that the search does not include the parent of a target of a
  CNAME record (except when the CNAME points back to its own path).

  If the target of a CNAME record is itself a CNAME record, the CA MAY
  follow it or MAY ignore it. In either case, the search continues at
  the parent of the label containing the initial CNAME.

  Processing for DNAME is exactly the same as for CNAME. Note that since
  DNAME records are implemented by creating the corresponding CNAME
  records on the fly, it is only necessary for DNAME records to appear
  on the wire for purposes of DNSSEC.





On Wed, Apr 5, 2017 at 3:43 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:

https://www.rfc-editor.org/errata_search.php?eid=4988

Rob Stradling said:

2. Bug?: Shouldn't this...
  o  If A(X) is not null, and CAA(A(X)), then R(X) =
     CAA(X), otherwise

...actually be this...

  o  If A(X) is not null, and CAA(A(X)), then R(X) =
     CAA(A(X)), otherwise

A further edit: "and CAA(A(X))" should be "and CAA(A(X)) is not empty"

Also, did you see my earlier suggestion on the list? I think now that we
aren't tree-climbing on CNAME targets, we can express this algorithm in
a more straightforward way that emphasizes its similarity to how other
DNS records are looked up:

----- Proposal -----
   Let CAA(X) be the record set returned by performing a CAA record
query on the domain name X, according to the name server lookup
algorithm specified in RFC 1034 section 4.3.2 (in particular including
CNAME responses). Let P(X) be the domain name produced by removing the
leftmost label of X.

 - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise
 - If P(X) is the root domain '.', then R(X) is empty, otherwise
 - R(X) = R(P(X))

----- End proposal -----

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--------------328989437D5E3E3A0641F125-- From nobody Tue Jun 6 21:57:32 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 DD166129C6A for ; Tue, 6 Jun 2017 21:57:29 -0700 (PDT) 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 zXI3ruPzf-Qb for ; Tue, 6 Jun 2017 21:57:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F9B129C64 for ; Tue, 6 Jun 2017 21:57:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 704947A3309; Wed, 7 Jun 2017 04:57:25 +0000 (UTC) Date: Wed, 7 Jun 2017 04:57:25 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170607045725.GI25754@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: [lamps] draft-ietf-lamps-eai-addresses-10 full review Part 1 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 04:57:30 -0000 On Fri, May 26, 2017 at 03:37:07PM -0400, Russ Housley wrote: > This is the LAMPS WG Last Call for "Internationalized Email Addresses in > X.509 Certificates� . Please review > the document and send your comments to the list by 9 June 2017. See below. > 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. s/Issuer Alternate Name/Issuer Alternative Name/ Is there actually a use-case for EAI email addresses in issuer alternative names? Are issuer alternative names used at all? > 1. Introduction > > [RFC5280] defines rfc822Name subjectAltName choice for representing s/rfc822Name subjectAltName choice/the rfc822Name subjectAltName name type/ > [RFC5321] email addresses. This form is restricted to a subset of s/This form/The syntax of rfc822Name/ > US-ASCII characters and thus can't be used to represent > Internationalized Email addresses [RFC6531]. To facilitate use of > these Internationalized Email addresses with X.509 certificates, this s/these// > document specifies a new name form in otherName so that > subjectAltName and issuerAltName can carry them. In addition this s/a new name form in otherName/a new otherName variant/ s/so that subjectAltName and issuerAltName can carry them// > document calls for all email address domain in X.509 certificates to > conform to IDNA2008 [RFC5890]. s/domain/domains/ s/conform to IDNA2008 [RFC5890]/conform to IDNA2008 [RFC5890], with non-ASCII domains encoded in A-label form/ > 3. Name Definitions > > The GeneralName structure is defined in [RFC5280], and supports many > different names forms including otherName for extensibility. This s/names forms/name forms/ > section specifies the SmtpUTF8Name name form of otherName, so that Given that email certificates pertain (primarily) to email messages and not email transport, perhaps SmtpUTF8Name is not the best term to introduce here? It is likely too late to suggest "UTF8MailboxName", but if not, it is clear and removes the out of place connection to SMTP. > Internationalized Email addresses can appear in the subjectAltName of > a certificate, the issuerAltName of a certificate, or anywhere else > that GeneralName is used. Well, not really *anywhere* else, since we're specifically excluding this name type in the context of name constraints. And it seems quite unlikely that it will appear anywhere other than as a subjectAltName. > When the subjectAltName (or issuerAltName) extension contains an > Internationalized Email address, the address MUST be stored in the > SmtpUTF8Name name form of otherName. The format of SmtpUTF8Name is But addresses with an all-ASCII localpart and a non-ASCII domain will be stored via rfc822Name with the domainpart converted to A-label form. So the above is perhaps misleading... > defined as the ABNF rule SmtpUTF8Mailbox. SmtpUTF8Mailbox is a > modified version of the Internationalized Mailbox which was defined > in Section 3.3 of [RFC6531] which was itself derived from SMTP > Mailbox from Section 4.1.2 of [RFC5321]. [RFC6531] defines the > following ABNF rules for Mailbox whose parts are modified for > internationalization: , , , > , , and . In particular, > was updated to also support UTF8-non-ascii. UTF8-non-ascii was > described by Section 3.1 of [RFC6532]. Also, sub-domain was extended > to support U-label, as defined in [RFC5890]. This too seems to invite a name that is more like "UTF8MailboxName" than "SmtpUTF8Name". Instead of trying to import the ABNF from multiple documents, which in turn import ABNF from yet more documents, ... It is perhaps time to consolidate the relevant definitions in place, with a single set of named building blocks. > This document further refines Internationalized [RFC6531] Mailbox > ABNF rules and calls this SmtpUTF8Mailbox. If not too late: s/SmtpUTF8Mailbox/UTF8Mailbox/ > In SmtpUTF8Mailbox, sub- > domain that encode non-ASCII characters SHALL use U-label Unicode > native character labels and MUST NOT use A-label [RFC5890]. What appears to be meant by "sub-domain" here is in fact a label. It would be more clear to avoid additional terminology for the same thing. And why "encode"? Better would be: In SmtpUTF8Mailbox, labels that include non-ASCII characters MUST be stored in U-label (rather than A-label) [RFC5890] form. > This > restriction prevents having to determine which label encoding A- or > U-label is present in the Domain. s/prevents/removes the need/ > As per Section 2.3.2.1 of > [RFC5890], U-label use UTF-8 [RFC3629] with Normalization Form C and > other properties specified there. s/U-label use/U-labels are encoded as/ s/with/in/ > In SmtpUTF8Mailbox, sub-domain > that encode ASCII character labels SHALL use NR-LDH restrictions as > specified by section 2.3.1 of [RFC5890] and SHALL be restricted to > lower case letters. s/sub-domain/domains/ s/encode/include/ It is not clear what the above is saying. Is it talking about all-ASCII labels? Or ASCII characters generally, possibly in U-labels? What are "NR-LDH restrictions"? I did not see any such term defined in rfc5890. What is defined is "NR-LDH label" (2.3.2.2). > One suggested approach to apply these sub- > domains restriction is to restrict sub-domain so that labels not > start with two letters followed by two hyphen-minus characters. This makes no sense at all, and should probably be removed. > Consistent with the treatment of rfc822Name in [RFC5280], > SmtpUTF8Name is an envelope and has no phrase (such as a > common name) before it, has no comment (text surrounded in > parentheses) after it, and is not surrounded by "<" and ">". Surely there's no need to drag in any mention of envelopes. If there is no ABNF construct elsewhere that gives just the desired address part, define it here. Trying to use ABNF by reference makes this document contorted and unclear. > Due to operational reasons described shortly and name constraint s/described/to be described/ > compatibility reasons described in its section, s/its section// > SmtpUTF8Name > subjectAltName MUST only be used when the local part of the email > address contains UTF-8. UTF-8 is an encoding, not content: s/containts UTF-8/contains non-ASCII characters/ > When the local-part is ASCII, rfc822Name > subjectAltName MUST be used instead of SmtpUTF8Name. The use of > rfc822Name rather than SmtpUTF8Name is currently more likely to be > supported. The second sentence would be better as: This is compatible with legacy software that supports only rfc822Name (and not SmtpUTF8Name). > Also use of SmtpUTF8Name incurs higher byte > representation overhead due to encoding with otherName and the > additional OID needed. This may be offset if domain requires non- > ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name > supports A-label. This is not sufficiently compelling to be mentioned. Please remove. > 4. IDNA2008 > > To facilitate comparison between email addresses, all email address > domain in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and > excludes any "mappings" mentioned in that document). s/domain/domains/ s/excludes/avoid/ > Otherwise non- > conforming email address domains introduces the possibility of > conversion errors between alternate forms. s/Otherwise/Use of/ > This applies to > SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName and > anywhere else that GeneralName is used. s/SmtpUTF8Mailbox/SmtpUTF8Name/ s/GeneralName is/these are/ > 5. Matching of Internationalized Email Addresses in X.509 certificates > > In equivalence comparison with SmtpUTF8Name, there may be some setup > work to enable the comparison i.e. processing of the SmtpUTF8Name > content or the email address that is being compared against. This is a lot of words to say very little or nothing at all. Delete or clarify. > The > process for setup for comparing with SmtpUTF8Name is split into > domain steps and local- part steps. The phrase "process for setup for comparing" is exceedingly convoluted, please fix. How about just: "Comparing SmtpUTF8Names consists of a domain-part step and a local-part step". > The comparison form for local- > part always is UTF-8. The comparison form for domain depends on > context. s/local-part/local-parts/ s/domain/domain-parts/ > Comparison of two SmtpUTF8Name is straightforward with no setup work > needed. They are considered equivalent if there is an exact octet- > for-octet match. What is expected to be compared are not two "SmtpUTF8Name" objects, but such an object with an email address, or such an object with an rfc822Name constraint. And, with NR-LDH labels, case insensitive comparison may be required. Why are we descibing comparisons that don't happen? > Comparison with other email address forms such as SmtpUTF8Name is not an "email address form", it is a GeneralName form. So "other email address forms" is not correct. > Internationalized email address or rfc822Name requires additional > setup steps. Domain setup is particularly important for forms that > may contain A- or U-label such as International email address, or > A-label only forms such as rfc822Name. Clarify or delete. > This document specifies the > process to transform the domain to U-label. (To convert the domain > to A-label, follow the process specified in section 7.5 and 7.2 in > [RFC5280]) Why the parenthetical comment? And we don't specify the process of transforming to U-label form. Rather we require such conversion when one of the addresses being compared employs A-labels. > The first step is to detect A-label by using section 5.1 > of [RFC5891]. s/A-label/use of A-labels/ > Next if necessary, transform the A-label to U-label > Unicode as specified in section 5.2 of [RFC5891]. Finally if > necessary convert the Unicode to UTF-8 as specified in section 3 of > [RFC3629]. s/the A-label/any A-labels/ s/U-label/U-labels/ Nobody will convert to UTF-8 in two separate steps. In practice a library will be used that converts from A-label form to UTF-8 encoded Unicode. > For ASCII NR-LDH labels, upper case letters are converted > to lower case letters. Fine. > In setup for SmtpUTF8Mailbox, the email > address local-part MUST conform to the requirements of [RFC6530] and > [RFC6531], including being a string in UTF-8 form. In particular, Given the below, I don't see any need for the above. > the local-part MUST NOT be transformed in any way, such as by doing > case folding or normalization of any kind. The part of > an Internationalized email address is already in UTF-8. > To summarize non-normatively, the comparison steps including setup > are: > > 1. If the domain contains A-labels, transform them to U-label. s/U-label/U-labels/ > 2. If the domain contains ASCII NR-LDH labels, lowercase them. > > 3. Ensure local-part is UTF-8. Since the local-part of email addressees is not accompanied by any encoding information, it is *presumptively* UTF-8, and there is nothing to do (or that can be done) in this step. > 4. Compare strings octet-for-octet for equivalence. > This specification expressly does not define any wildcards characters s/wildcards/wildcard/ > and SmtpUTF8Name comparison implementations MUST NOT interpret any > character as wildcards. Instead, to specify multiple email addresses > through SmtpUTF8Name, the certificate SHOULD use multiple s/SHOULD/MUST/ > subjectAltNames or issuerAltNames to explicitly carry those email > addresses. s/those/any additional/ More to follow. -- Viktor. From nobody Tue Jun 6 23:53:56 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 D573E126D46 for ; Tue, 6 Jun 2017 23:53:54 -0700 (PDT) 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 QCp0JC8DfrdJ for ; Tue, 6 Jun 2017 23:53:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA2B127337 for ; Tue, 6 Jun 2017 23:53:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EFC177A3309; Wed, 7 Jun 2017 06:53:51 +0000 (UTC) Date: Wed, 7 Jun 2017 06:53:51 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170607065351.GL22954@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <149521958261.27235.13262265548463695364@ietfa.amsl.com> <50D23BF4-65DA-4895-B181-C4D0F2004E78@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D23BF4-65DA-4895-B181-C4D0F2004E78@vigilsec.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [lamps] [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 07 Jun 2017 06:53:55 -0000 On Mon, May 22, 2017 at 04:11:52PM -0400, Russ Housley wrote: > I think that the newly posted I-D contains the agreed approach. Does anyone think otherwise? I think that the technical issues are (mostly?) resolved. However, the exposition still needs work. I've sent out the first part of my review. I'll send the second part when I've had a chance to finish reading and responding to the remaining sections. The most significant issue so far is that in trying to not provide a full address ABNF, and instead specify deltas to existing grammars in other RFCs, the document's terminology and clarity suffer a great deal. Perhaps it is time to just import the relevant definitions by value rather than by reference, and optimize for clarity, at the cost of some repetiion of the content of prior RFCs. -- Viktor From nobody Mon Jun 12 13:39:19 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 C627F129AA8 for ; Mon, 12 Jun 2017 13:39:13 -0700 (PDT) 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 3Dw0i7w4RsFD for ; Mon, 12 Jun 2017 13:39:12 -0700 (PDT) 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 13F731293E8 for ; Mon, 12 Jun 2017 13:39:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7CB9A3002C1 for ; Mon, 12 Jun 2017 16:39:11 -0400 (EDT) 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 kJUFTfKy0ORP for ; Mon, 12 Jun 2017 16:39:10 -0400 (EDT) Received: from new-host-5.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7A699300265 for ; Mon, 12 Jun 2017 16:39:10 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 12 Jun 2017 16:39:10 -0400 References: <149521958261.27235.13262265548463695364@ietfa.amsl.com> <50D23BF4-65DA-4895-B181-C4D0F2004E78@vigilsec.com> <20170607065351.GL22954@mournblade.imrryr.org> To: LAMPS In-Reply-To: <20170607065351.GL22954@mournblade.imrryr.org> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jun 2017 20:39:14 -0000 Viktor: Your response implies that there is a second part to your review coming. = WG Last Call need last Friday. Please post any remains comments very = soon so that we can get an updated document. Russ > On Jun 7, 2017, at 2:53 AM, Viktor Dukhovni = wrote: >=20 > On Mon, May 22, 2017 at 04:11:52PM -0400, Russ Housley wrote: >=20 >> I think that the newly posted I-D contains the agreed approach. Does = anyone think otherwise? >=20 > I think that the technical issues are (mostly?) resolved. However, > the exposition still needs work. I've sent out the first part of > my review. I'll send the second part when I've had a chance to > finish reading and responding to the remaining sections. >=20 > The most significant issue so far is that in trying to not provide > a full address ABNF, and instead specify deltas to existing grammars > in other RFCs, the document's terminology and clarity suffer a > great deal. Perhaps it is time to just import the relevant > definitions by value rather than by reference, and optimize for > clarity, at the cost of some repetiion of the content of prior > RFCs. >=20 > --=20 > Viktor From nobody Tue Jun 13 07:20: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 D7F52128959 for ; Tue, 13 Jun 2017 07:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 hIm7f_8pZOBn for ; Tue, 13 Jun 2017 07:19:55 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 37A89131877 for ; Tue, 13 Jun 2017 07:19:32 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id b6so19276007oia.1 for ; Tue, 13 Jun 2017 07:19:32 -0700 (PDT) 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=Gwd4WZPisPmtR6jlVr0Kd7jIta8cgd6G/JfdK7V4mq8=; b=XDBQTS+ccEvGza7DOLeCyDiUKkzYdZCz8sKoPUNRRr99fiz+PaqPj53NYL89MQhe/h Yc2HvtDGuOTEXZMJSBjEHng7TjoaGx9WJSKKjFZWu5jby40O0FTWcDtpvMlsUROLUrOm yTlC3OmmSOmh4kizNx0tEoJt7qf+5YAWlqp4ZYv1u4HOBCJFfycpZcNEo1FqS3+koWlP 7hH42uHVYmqwZrXox90Uueg6t2DGTJx/6+p4/uFeWoowYogD+FxiaQ20ZcXJJF1xqtlE HgyRzuhYJ55wzJ/WYVl8xYVmxpX/UIn1rWh8kl75od/G5B3IyWihq26KARToSwnIiSgI mDDw== 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=Gwd4WZPisPmtR6jlVr0Kd7jIta8cgd6G/JfdK7V4mq8=; b=tPTr/jrphlSvMoWEGa7k9sLC3BVUFPm92kRJUV0zbEGJDCq0nvrU3RRroXj6DblG3/ r+Ae4+I73UFJKCDPr27z9MRRtmoYvB8+opfPRplllG/oeIHoVJZPbuAkAjZKn01W8Wnk PJIhyX6IevfXm521tNw7QxKPjcszK3nqNv8eXW9VZLj2Y/YxwmIyigGRr4G93Wp2aQuX jghVN3z2tMnDf4iUmKP5jcP0345ZrSUzt9Q+t3tIdFr/q1IEMjSW1S8v4nUojcra0pvZ 5wcmCs1LMJCaucs34S42J5vK0JezTICW6dZf2DDIrsDiwbzEk/8/YBQtvqFoR6GtjdKR 1Udw== X-Gm-Message-State: AKS2vOyZDAJ1Iql/IiumMPrS5Pzq+np+9BhqlawgSP+RHB4jfAECPXAD qxG//ZeuVbi3G3edBmIGujp0JOgP0A== X-Received: by 10.202.212.73 with SMTP id l70mr70695oig.4.1497363571457; Tue, 13 Jun 2017 07:19:31 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Tue, 13 Jun 2017 07:19:30 -0700 (PDT) In-Reply-To: References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 10:19:30 -0400 X-Google-Sender-Auth: JnkIyby__dxKLVqdfDbT6w9ZCKs Message-ID: To: Jacob Hoffman-Andrews Cc: SPASM , Rob Stradling Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 14:20:01 -0000 On Tue, Jun 6, 2017 at 12:24 PM, Jacob Hoffman-Andrews wrote: > Great! I was giving a final read-through and noticed a couple more problems. > Sorry I didn't spot these on the first read: > >> Note that the search does not include the parent of a target of a >> CNAME record (except when the CNAME points back to its own path). > > It's not clear what "back to its own path" means here. How about "unless it > happens to be the result of one of the P(X) lookups in the algorithm above" > >> If the target of a CNAME record is itself a CNAME record, the CA MAY >> follow it or MAY ignore it. In either case, the search continues at >> the parent of the label containing the initial CNAME. > > This seems to introduce a normative statement that CAs need only chase CNAME > alias record chains one level deep, when the rest of DNS assumes that you > will chase them arbitrarily deep, with loops treated as an error: > > RFC 1034 3.6.1: >> CNAME chains should be followed and CNAME loops signalled as an error. > > It's undesirable to introduce these two MAYs because they creates ambiguity > in how different CAs will interpret a given CAA configuration containing > chained CNAMEs. > > I think we should remove the paragraph starting with "If the target of a > CNAME record..." The ambiguity is inescapable. An implementation may be following the old or the new rule. I think it is better to point out that ambiguity exists. Unless there is a really good reason, I am opposed to further changes. From nobody Tue Jun 13 09:41:00 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 32899129436 for ; Tue, 13 Jun 2017 09:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.org 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 GUobotzFN8Wx for ; Tue, 13 Jun 2017 09:40:57 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6A812EB44 for ; Tue, 13 Jun 2017 09:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=yTZA2iae+V8vQBWyJ9Y76cyJKJ5ZX38HIBtxuql0uNk=; b=3PolymOCohh7IFoC2nOmh9DLZrQMA9jpA/IS+rEtnanYvg1JXNVSYorWd+KwBB3A8gVvitPEkBDlfzDu8G5vGxE0gF9Y6BY9eOQKLNEju0gwkLFH1torYP/cKrec2sZZs3zCW8c2Ukbu+enX3kQVe10YTNQ3Qowi6ofAy9wosJ4=; Received: ; Tue, 13 Jun 2017 09:40:56 -0700 To: Phillip Hallam-Baker Cc: SPASM , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> From: Jacob Hoffman-Andrews Message-ID: <021b346f-966e-377b-a242-73d3613921b0@eff.org> Date: Tue, 13 Jun 2017 09:40:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 16:40:59 -0000 On 06/13/2017 07:19 AM, Phillip Hallam-Baker wrote: >>> If the target of a CNAME record is itself a CNAME record, the CA MAY= >>> follow it or MAY ignore it. In either case, the search continues at >>> the parent of the label containing the initial CNAME. >> This seems to introduce a normative statement that CAs need only chase= CNAME >> alias record chains one level deep, when the rest of DNS assumes that = you >> will chase them arbitrarily deep, with loops treated as an error: >> >> RFC 1034 3.6.1: >>> CNAME chains should be followed and CNAME loops signalled as an error= =2E >> It's undesirable to introduce these two MAYs because they creates ambi= guity >> in how different CAs will interpret a given CAA configuration containi= ng >> chained CNAMEs. >> >> I think we should remove the paragraph starting with "If the target of= a >> CNAME record..." > The ambiguity is inescapable. An implementation may be following the > old or the new rule. I think it is better to point out that ambiguity > exists. Ah, now I see. Is your intent with this paragraph to say that CAs MAY follow the old tree-climbing behavior? Because that's not what it says currently. It says that CAs may terminate CNAME following after following a single CNAME. For instance if you have: www.example.com CNAME validation.example.net validation.example.net CNAME server123.example.net server123.example.net CAA "ca.example.com" This paragaph says that the CA MAY choose not to follow that second CNAME= =2E Also, I think it's incorrect to say that this ambiguity exists. We should specify clearly what the correct behavior under this erratum is, and simply mention "some CAs may implement an earlier version of the CAA spec, with X behavior." But that behavior wouldn't be following the erratum behavior. From nobody Tue Jun 13 10:04:57 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 194F51318AC for ; Tue, 13 Jun 2017 10:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KXsSiNEtDe06 for ; Tue, 13 Jun 2017 10:04:54 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 C37411316EF for ; Tue, 13 Jun 2017 10:04:54 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id k4so92568669otd.0 for ; Tue, 13 Jun 2017 10:04:54 -0700 (PDT) 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=9JyCh/E6s8YPBBV9DNQkdnN6v2Y60SPTHtDoONeqaek=; b=QEeLNpamGf97PEnBNBWkcVgqt3AC4bhY0KSLxyShMaj/M4hp88Eb+f5l+8d0lQTMBM 81Tlvy2sK7xs6nwVod707IlOV53U/zUF2Y5+KVhxx3OIT02eMu+ePf2RQbQcG0eqh+7p CdGSm5FVVg+72B70n86sxWhJT6WFt8Tjd8TARSd+nwwIVQD6wwpDJSJ8ZOJD+SzKvvD+ thyJ29SYhvAk6KfJiDqqn89lM2fmpnwa9F/SyLmQv5hoBvRBe4I15L7bFeWZAww6zoSH V/Mex0ddHfFPIL1sLWsHHyhFgJLBLbHzojefswms2CTdL0OX25Ja0lekNPB4Lv7WdE7f VQbw== 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=9JyCh/E6s8YPBBV9DNQkdnN6v2Y60SPTHtDoONeqaek=; b=Nl7jGTIG/aeGuSNJXAkEmPwdFshsOQ2zoDe1cSQEpdMkGpwxs+Ac91c2ep1KHnH7Zb kkn94QVlD8kVaTZFvbJ0YtMeVgL/P20q/As9i7qWhLSHGbw5qnHp7q6nd+R60kUV3KxT 5q9jRizOeNYtZFVRQN4nyRo+bPOttSxJ2gB67j3lpNeQlxWBZZr0TUawrgJMkxkC4lDg K/BKStWOu91PQwYSwkRHSWttTOEmh6oTLD6BDJkcRW4uPVA99GVMFDIE3KYtQKiMjD9f 6x5AQwKUpIyWM/YqvWkgqmEzXfkMQ6wE9xfFieLR4V65Xl4x4ey3Z4ZL4jyVmFyTscdo Hqsw== X-Gm-Message-State: AKS2vOwyZiPteWeSHiJHOuRcMFRwll2IHKYGBsP/VVcRuuf3cZWkTG8d dxgjNY1CU3WDLEW3QjsQSVPzdhwFOQ== X-Received: by 10.157.0.73 with SMTP id 67mr798786ota.112.1497373493787; Tue, 13 Jun 2017 10:04:53 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Tue, 13 Jun 2017 10:04:53 -0700 (PDT) In-Reply-To: <021b346f-966e-377b-a242-73d3613921b0@eff.org> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 13:04:53 -0400 X-Google-Sender-Auth: 7hKuVbKYq3cwy26YetRYVvkpTwQ Message-ID: To: Jacob Hoffman-Andrews Cc: SPASM , Rob Stradling Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 17:04:56 -0000 Ah now I know that the issue was. Back in the vagaries of DNS. The problem is that CNAME is not supposed to point to a CNAME but frequently does. CAs may implement a limit on the number of chained CNAME links they follow. So maybe reword to explicitly state that if we have a CNAME chain like that, CAs may set a processing limit (provided they declare it) ? On Tue, Jun 13, 2017 at 12:40 PM, Jacob Hoffman-Andrews wrote: > On 06/13/2017 07:19 AM, Phillip Hallam-Baker wrote: >>>> If the target of a CNAME record is itself a CNAME record, the CA MAY >>>> follow it or MAY ignore it. In either case, the search continues at >>>> the parent of the label containing the initial CNAME. >>> This seems to introduce a normative statement that CAs need only chase CNAME >>> alias record chains one level deep, when the rest of DNS assumes that you >>> will chase them arbitrarily deep, with loops treated as an error: >>> >>> RFC 1034 3.6.1: >>>> CNAME chains should be followed and CNAME loops signalled as an error. >>> It's undesirable to introduce these two MAYs because they creates ambiguity >>> in how different CAs will interpret a given CAA configuration containing >>> chained CNAMEs. >>> >>> I think we should remove the paragraph starting with "If the target of a >>> CNAME record..." >> The ambiguity is inescapable. An implementation may be following the >> old or the new rule. I think it is better to point out that ambiguity >> exists. > Ah, now I see. Is your intent with this paragraph to say that CAs MAY > follow the old tree-climbing behavior? Because that's not what it says > currently. It says that CAs may terminate CNAME following after > following a single CNAME. For instance if you have: > > www.example.com CNAME validation.example.net > validation.example.net CNAME server123.example.net > server123.example.net CAA "ca.example.com" > > This paragaph says that the CA MAY choose not to follow that second CNAME. > > Also, I think it's incorrect to say that this ambiguity exists. We > should specify clearly what the correct behavior under this erratum is, > and simply mention "some CAs may implement an earlier version of the CAA > spec, with X behavior." But that behavior wouldn't be following the > erratum behavior. > From nobody Tue Jun 13 10:08: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 58FBA129410 for ; Tue, 13 Jun 2017 10:08:20 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 9EuuEqmepAcw for ; Tue, 13 Jun 2017 10:08:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 0F46D1318F7 for ; Tue, 13 Jun 2017 10:08:19 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DH87Xo002022; Tue, 13 Jun 2017 18:08:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=r05wWQqz86nZlVxsAFi0Fig/XrN7G6EkSOmJEJTRVNs=; b=NywhFr48MG8IXUVXaZiVUj/ramfgezq/QbGmULqdCK7dADVDRPZyuQom1Mb19BzTNvPQ 2Ru+sheOMSL//1lm7cCyeUtlcj4Vkc1CfHNgkPyhkSdm9CQSmg2m6KNza+S3qUvHSz6o cbfJ7if8eCbenYZwFi76vEmosdCxlYYSEiMYtnkHMHNZjSsDkUAAiNLpi/pbd0TVdU7s mHmgk3FIv7a1IBFE7/QJ6yMyHDu9Lzkt2Wb9kIy/ACxoAjcje1f/11Eh0Hhn8mEWeeRy 5Al0+KthKvUzK0tKp6XW+/6j9B/PRF9W+pkJAW7JDWkQfsAcoApICD3nNHdc6Lxah69t ZQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2b29hrchyv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 18:08:09 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DH5cIp032687; Tue, 13 Jun 2017 13:07:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b0c3uyq18-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 13:07:48 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 13:07:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 13 Jun 2017 13:07:47 -0400 From: "Salz, Rich" To: Phillip Hallam-Baker , Jacob Hoffman-Andrews CC: SPASM , Rob Stradling Thread-Topic: [lamps] [Spasm] Erratum 4988 Thread-Index: AQHS3ilYogFLC+R7ukilGRln4U1clKIXFg8AgAEMMwCAACcagIAK3YMAgAAnhACAAAaxgP//vbHg Date: Tue, 13 Jun 2017 17:07:46 +0000 Message-ID: <24a7632277fa488c82c1975a7df90a47@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.162] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130295 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130296 Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 17:08:20 -0000 > The problem is that CNAME is not supposed to point to a CNAME but > frequently does. CAs may implement a limit on the number of chained > CNAME links they follow. Where does it say that? From nobody Tue Jun 13 10:24:27 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 108D913199B for ; Tue, 13 Jun 2017 10:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HDppKV2lqlHR for ; Tue, 13 Jun 2017 10:24:21 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 AFA621319A6 for ; Tue, 13 Jun 2017 10:24:14 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id a2so93000712oth.2 for ; Tue, 13 Jun 2017 10:24:14 -0700 (PDT) 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=/n1HadxGx5GsjU/mtmuaEbXPrELLIptt1zzcE6Ikg/0=; b=jbpygX4Fo+MMeZCyjLj3tLBUXzF2Hn5lmBDm5bgxW11yyZ12iEydMRkOokW+XUQ7ck jwBdO3eoKrPTjod6N5QEAbu03EFHkuaOX5tQbPhS5KjgAX0TBtVGJ8p24I3sEHjtIU/d 3gDhjxWzhih+Y3NPJlaUCTO/LXVNsQZLky92VRvU6R/69kd31U2/aisvm3sGDWrdo/pv mEN7Tvl4w75d5pxl0LJ5yvFcYz4NWe9pCZZClwyIlgiLB+ZFIJ4U4dXw8mmrR5R7m7lc 8S4+lN6iPxp/GYGRKNWgHDpe0i14uLGzyiv1o11VhyBOsk04T2Ejm+tk5HQ9tukLrnpq 3+Kw== 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=/n1HadxGx5GsjU/mtmuaEbXPrELLIptt1zzcE6Ikg/0=; b=KWnOmcp4dv9NV5B1sD5AGrZYZNFx3wOnlHHPvNJj5UYxH+hshIeF9qzq9/XX1DUUob SgVXwZJSR/bbDa+VOaeOHqsYxfAnd2uWBiCOfNXJHxHyukBZp1R4w78edKxqKkH/ShkR XiWfRHKmFQ2Ua/lmn+opafgIBpCE+nQeSwB16Va8biPm4QuhuFf9CAsABu8kFi1LywBj t2P/l+qyragnuY0wDTPz4gClsU8FwK+1MGO8oHq5iQIMSgDWCobIZI3aBXrVbcwDsYdX MsxUuxax1MHMYzr0eBA0FuDTsbpzvPMeF6bm26BmqGhABBld69ocSCti4wqZeW4/6483 //Tg== X-Gm-Message-State: AKS2vOwIi4/+tT6GTH9VTxap2yYvCPMWkSeaDotGcazK9GQXkrCbC7Q2 rJ5c7lR6KnGfUUBtKN3SiUAJanl4Jw== X-Received: by 10.157.10.19 with SMTP id 19mr855477otg.100.1497374654107; Tue, 13 Jun 2017 10:24:14 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Tue, 13 Jun 2017 10:24:13 -0700 (PDT) In-Reply-To: <24a7632277fa488c82c1975a7df90a47@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <24a7632277fa488c82c1975a7df90a47@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 13:24:13 -0400 X-Google-Sender-Auth: bM8csBh6wsv8VC7OCa69SqLjLM8 Message-ID: To: "Salz, Rich" Cc: Jacob Hoffman-Andrews , SPASM , Rob Stradling Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 17:24:23 -0000 On Tue, Jun 13, 2017 at 1:07 PM, Salz, Rich wrote: >> The problem is that CNAME is not supposed to point to a CNAME but >> frequently does. CAs may implement a limit on the number of chained >> CNAME links they follow. > > Where does it say that? https://tools.ietf.org/html/rfc1034 3.6.2. Aliases and canonical names Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be: 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU rather than pointing at USC-ISIC.ARPA. Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. It is this sort of drafting that makes dealing with DNS difficult. Whatever you try to write, you build on quicksand. From nobody Tue Jun 13 10:29:47 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 1FB9C1319E4 for ; Tue, 13 Jun 2017 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xT80qi3lxIyI for ; Tue, 13 Jun 2017 10:29:44 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 6A26D1319D1 for ; Tue, 13 Jun 2017 10:29:44 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id k4so93075232otd.0 for ; Tue, 13 Jun 2017 10:29:44 -0700 (PDT) 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=8i7vW+Rv9SGe7tyluPFHWeNHwPngdHhd6U6J8S6qShg=; b=c3wUPwQtC97XVN6Ml7ILIc14hDTGDe7zEDBailm9YUn/nln6PHLpqXGM9O4usJzAwB /yJ+HYas78IpObqWHsCVz6ixlWbEfCH8NxjqHhsNmMvVwEDqhaENuqrJdcMXaXGrqLbh STrNkY395qip8STJvZk3coYX3pc0nb72Ow1oKFfG1H8ZSWjoVxZSTzzRJq59N88K5vlf tF+ynZ3f1hVHCML/x5pgbpwDZJN9zbrnhJF30vHoPv3keeHjzxlG6kUlu/s7BZr/Dzq8 aGQmf4hpgExkSow6ZnOMmM29l7tMfdTMw0LVXRy8Ez7P25L+hIXd054kH6vqaXSeLGmx iI2g== 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=8i7vW+Rv9SGe7tyluPFHWeNHwPngdHhd6U6J8S6qShg=; b=NV+054Q88k2zJsBkmLRhM86P3ULceqCm0LzyqGb45PNEl3/bFfbRfCSyR25b7f7z+q UpI+r13e63xdI4F2tf+41ZHkLc8rTNxecuo1uf4OxnM1tR+dmgRbu2nw/uEw5VSOmRI6 M8GcMCamsIYwbrK9+EIozGSFn27uc+UHCGwJdy1saCASyMPo0/cbAbiMbwtnm88aICNO 3bABzQQiJDoTcRmoKsH+TyrhafERIpus3gYsQZNi06q3VMhc8xWo7UQVD8LO3SVJC64w 4j9+q0SHKaJu1ibci2YT3Q6u5NyPDVr0/oIWBbx1y3s9biHTb2sZ/KfDEWcRt42hyOOO bvBQ== X-Gm-Message-State: AKS2vOw9udcWrRuUFJWo1VlhSglmYV5KO8J/HUnRO5wzAIqTOFmOuARv Uf5On65BTQciZf1AKWOPQd05kgq/wQ== X-Received: by 10.157.44.102 with SMTP id f93mr815985otb.199.1497374983853; Tue, 13 Jun 2017 10:29:43 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Tue, 13 Jun 2017 10:29:43 -0700 (PDT) In-Reply-To: References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <24a7632277fa488c82c1975a7df90a47@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 13:29:43 -0400 X-Google-Sender-Auth: tKl6kGeLrfp1n6xa3jedC9ar7os Message-ID: To: "Salz, Rich" Cc: Jacob Hoffman-Andrews , SPASM , Rob Stradling Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 17:29:46 -0000 On Tue, Jun 13, 2017 at 1:24 PM, Phillip Hallam-Baker wrote: > On Tue, Jun 13, 2017 at 1:07 PM, Salz, Rich wrote: >>> The problem is that CNAME is not supposed to point to a CNAME but >>> frequently does. CAs may implement a limit on the number of chained >>> CNAME links they follow. >> >> Where does it say that? > > https://tools.ietf.org/html/rfc1034 > 3.6.2. Aliases and canonical names > > Domain names in RRs which point at another name should always point at > the primary name and not the alias. This avoids extra indirections in > accessing information. For example, the address to name RR for the > above host should be: > > 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU > > rather than pointing at USC-ISIC.ARPA. Of course, by the robustness > principle, domain software should not fail when presented with CNAME > chains or loops; CNAME chains should be followed and CNAME loops > signalled as an error. > > > It is this sort of drafting that makes dealing with DNS difficult. > Whatever you try to write, you build on quicksand. Oh and it is updated and clarified in several places. But not to change the above as far as I can see. But there are a dozen updates. From nobody Tue Jun 13 10:50: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 E288A12942F for ; Tue, 13 Jun 2017 10:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 4H2_i6cQXJkZ for ; Tue, 13 Jun 2017 10:50:29 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 3E76D12940C for ; Tue, 13 Jun 2017 10:50:29 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DHoKlV021375; Tue, 13 Jun 2017 18:50:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=njn9zgcUNikbe0ixkC/x3Z+H7HNB2kDc8PywRoMmFDQ=; b=fRRSVcz1q3aUZID1GkU1O7+VTdKgllDoqjdCVf4kfeN1Q1ZraS6G6g/beFG0dXyBp1fn FldlqSYDJQfJ67YhoWIEEf1xYmyb1HTH83bGPWi//mFvo6BMSJZs6CkVi1wHswYwsJo4 OFX8pAAjgYxkLau8gEiKGSgsC73P5M0gGMLhp0dyQHV3XVNg/b3hbfBHzkf0WTDeWWMB PpvxbQS/unuWHttFyXEbS5is1V7qTGzE9SMHoe25TgGtEfjdk40WykES9pGPFRBjPyj5 6qb3fXw4+li2xU9XKpX0h+pF+oolpoflFVPQTc7a/vajKEn0UlhZlunLZWYY4r2glKJ5 MA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b1rnbs1g6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 18:50:19 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DHju6g009765; Tue, 13 Jun 2017 13:50:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3uayrw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 13:50:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 13:50:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 13 Jun 2017 13:50:13 -0400 From: "Salz, Rich" To: Phillip Hallam-Baker CC: Jacob Hoffman-Andrews , SPASM , "Rob Stradling" Thread-Topic: [lamps] [Spasm] Erratum 4988 Thread-Index: AQHS3ilYogFLC+R7ukilGRln4U1clKIXFg8AgAEMMwCAACcagIAK3YMAgAAnhACAAAaxgP//vbHggABHtoCAAAGKgP//wjrw Date: Tue, 13 Jun 2017 17:50:13 +0000 Message-ID: References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <24a7632277fa488c82c1975a7df90a47@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130305 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130305 Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 17:50:33 -0000 PiA+ICAgICA1Mi4wLjAuMTAuSU4tQUREUi5BUlBBICBJTiAgICAgIFBUUiAgICAgQy5JU0kuRURV DQo+ID4NCj4gPiByYXRoZXIgdGhhbiBwb2ludGluZyBhdCBVU0MtSVNJQy5BUlBBLiAgT2YgY291 cnNlLCBieSB0aGUgcm9idXN0bmVzcw0KPiA+IHByaW5jaXBsZSwgZG9tYWluIHNvZnR3YXJlIHNo b3VsZCBub3QgZmFpbCB3aGVuIHByZXNlbnRlZCB3aXRoIENOQU1FDQo+ID4gY2hhaW5zIG9yIGxv b3BzOyBDTkFNRSBjaGFpbnMgc2hvdWxkIGJlIGZvbGxvd2VkIGFuZCBDTkFNRSBsb29wcw0KPiA+ IHNpZ25hbGxlZCBhcyBhbiBlcnJvci4NCg0KWW91IGFyZSBtaXNyZWFkaW5nIHRoZSBzcGVjLiAg Rmlyc3QsIHRoZSBxdW90ZWQgZXhhbXBsZSBpcyBQVFIgcmVjb3Jkcywgbm90IENOQU1FLiAgU2Vj b25kLCB0aGUgdGV4dCBhbGtzIGFib3V0IENOQU1FIGxvb3BzIGFuZCBjaGFpbnMsIGlmIGhvdyBj YW4geW91IGhhdmUgZWl0aGVyIHdpdGhvdXQgYSBDTkFNRSBwb2ludGluZyB0byBhIENOQU1FPw0K DQoNCg== From nobody Tue Jun 13 12:04:54 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 82B92129488 for ; Tue, 13 Jun 2017 12:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 B_sSc3mzSYoy for ; Tue, 13 Jun 2017 12:04:50 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 D55AA12952E for ; Tue, 13 Jun 2017 12:04:50 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id a2so94952254oth.2 for ; Tue, 13 Jun 2017 12:04:50 -0700 (PDT) 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=hYTFY9s1nueRceqxJZMjIsnBW24grgpSESALq/O3mvU=; b=d12/lQdKUjq9MwI8nVC6jwRPmQ836EaG1l4N4RCTvlpKYChosapCIhIMHIfaXWoXu1 9KovOmIn7w+ZyGfNoykuPd5NF2wgrIAnnK0/ZKUm42ABVI+weCQtsWk2NHKxU2ZbOic2 T0MAGUSD43djGk8RjEbZfMQXyRxfj6DfDHJELmPYMu9/92csjn26IfRgmFh3t5qD37XW wqMp9f7D131R5EnZnYJsfB6DttFix0eVA3qG9yjf4/FTPpHxOILWGPBDxtmGKI1cWnLc 0e5QjuRh4Mv1PslV2+9k2xwanKYRNuX8xX8uVmH5jXFhOEBJjgyAkQMqmzvjzsjcgdJX x04g== 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=hYTFY9s1nueRceqxJZMjIsnBW24grgpSESALq/O3mvU=; b=nfNfUWh+LdVsDVhJwugSAgranJCaBm4CkDStr0UkU3MA4Z5LO6pwm1o7WeoulOO34+ HlF7sfHaLNXMEqmLi5COSbrwpVSeJbp0e+FdHRaXGe/CXyG4dq7ow09NtEs5wkcIIdx5 +1WvQU8zLf6nDgUBiRhUdYgFRyug4a/XuWNmnhEFpWxMFEKQ3TsgKe5S3fsZ8p2l+E91 sQGsj3J0iUqmeQq4iNX+gEYeF1VXHwE6YoODKEQ0L/PBpwcWlrZelPslFyRxt4frwvad hizyk9XMS0/7iqhxTMnbpph/Y6k8/Twb1hegZCr4yrh2W7tuvbP7ZFqiCNlku4c5Oy+Q 27SQ== X-Gm-Message-State: AKS2vOzbuXqqs5CKSHBkp2gaIEW2cuYrrfZFCSebO0Ujax2T+B7HDOke c+1+sVsPr1YxbeKy5aFIzWz3OPzWww== X-Received: by 10.157.10.19 with SMTP id 19mr1133789otg.100.1497380690289; Tue, 13 Jun 2017 12:04:50 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Tue, 13 Jun 2017 12:04:49 -0700 (PDT) In-Reply-To: References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <24a7632277fa488c82c1975a7df90a47@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 15:04:49 -0400 X-Google-Sender-Auth: INHXqcwUob0IinKIibTSp5ygsEk Message-ID: To: "Salz, Rich" Cc: Jacob Hoffman-Andrews , SPASM , Rob Stradling Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 19:04:52 -0000 On Tue, Jun 13, 2017 at 1:50 PM, Salz, Rich wrote: >> > 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU >> > >> > rather than pointing at USC-ISIC.ARPA. Of course, by the robustness >> > principle, domain software should not fail when presented with CNAME >> > chains or loops; CNAME chains should be followed and CNAME loops >> > signalled as an error. > > You are misreading the spec. First, the quoted example is PTR records, not CNAME. Second, the text alks about CNAME loops and chains, if how can you have either without a CNAME pointing to a CNAME? > > "Domain names in RRs which point at another name should always point at the primary name and not the alias." Seems pretty clear to me. The part about loops is prefixed with "Of course, by the robustness principle". From nobody Tue Jun 13 12:39: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 91AB712954B for ; Tue, 13 Jun 2017 12:39:32 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 XyA1-0BAMIBS for ; Tue, 13 Jun 2017 12:39:30 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 AA3C4129540 for ; Tue, 13 Jun 2017 12:39:30 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DJb2SP007584; Tue, 13 Jun 2017 20:39:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=PW3kCNCU292k5zZFZ7BjUyDE5f7vhJ0jX++uGEzz/HQ=; b=AAMXLaOINrdQhYIZPqkZL6xho0BM2hpP+hj8WHk3o8lURni6lq1XQcr+Tr3SKrz7EMXS xCHBB1SK68oGwLH/W556kLxZ6ZPg6rtO9eEHdtXEgOFztvmup9PMNZ86wvpqtCqIgkUY I/AMS4326LQ4e0/Gtawp6NKNg3b/0zEfoNi9uGOyI+M30LiDV2IiyThz051DX9o1Q4Xr M9syBJi0EWUGHWpcoYh2iEfSO15/ZtXyul5Mj0EHBgPSC7LQ4Ik8tym5HInYzX5gEEmN n2BsopnccaCrberIyKGMjKA6ugy1OGcX8H3ZuPhbD/JI66DBvw91LQb37EziE3u7b+C5 wA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2b2javsu9n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 20:39:22 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DJa2vv019387; Tue, 13 Jun 2017 15:39:20 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3ukb8y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 15:39:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 15:39:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 13 Jun 2017 15:39:20 -0400 From: "Salz, Rich" To: Phillip Hallam-Baker CC: Jacob Hoffman-Andrews , SPASM , "Rob Stradling" Thread-Topic: [lamps] [Spasm] Erratum 4988 Thread-Index: AQHS3ilYogFLC+R7ukilGRln4U1clKIXFg8AgAEMMwCAACcagIAK3YMAgAAnhACAAAaxgP//vbHggABHtoCAAAGKgP//wjrwgABYWID//8ZSsA== Date: Tue, 13 Jun 2017 19:39:19 +0000 Message-ID: References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <24a7632277fa488c82c1975a7df90a47@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130331 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130332 Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 19:39:32 -0000 IA0KPiAiRG9tYWluIG5hbWVzIGluIFJScyB3aGljaCBwb2ludCBhdCBhbm90aGVyIG5hbWUgc2hv dWxkIGFsd2F5cyBwb2ludCBhdA0KPiB0aGUgcHJpbWFyeSBuYW1lIGFuZCBub3QgdGhlIGFsaWFz LiINCj4gDQo+IFNlZW1zIHByZXR0eSBjbGVhciB0byBtZS4gVGhlIHBhcnQgYWJvdXQgbG9vcHMg aXMgcHJlZml4ZWQgd2l0aCAiT2YgY291cnNlLA0KPiBieSB0aGUgcm9idXN0bmVzcyBwcmluY2lw bGUiLg0KDQpXZWxsIDEwMzYgcHJlZGF0ZXMgU0hPVUxEIE1VU1QgZXRjLiAgQnV0IGl0IGRvZXMg c2F5IHNob3VsZCA6KQ0KDQpBbmQgYW55d2F5LCBDTkFNRSBwb2ludGluZyB0byBDTkFNRSBpcyBj b21tb24uICBQZXJoYXBzIGl0J3MgdGltZSBmb3IgeWV0IGFub3RoZXIgdXBkYXRlIHRvIDEwMzYu DQo= From nobody Tue Jun 13 12:53:06 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 5BAFA129687 for ; Tue, 13 Jun 2017 12:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.org 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 KesDbt4zFz7D for ; Tue, 13 Jun 2017 12:53:03 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18405129577 for ; Tue, 13 Jun 2017 12:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=8VqkJl+tiAGnn8SL5xbh2uP7GSem7waZgJjmTAae2b8=; b=p8k+E+vRKnUvKeA0/vAdepExhvKsHM7RZTp6RC5yKA7bqfNXeoADVYI4AQLE0vYPj6uVpWGOZvsp6tQCATQ1LE3pif4v36N9fSwNo3566r4kFxf9w2hEf9W2eztP2s4OsenLK9qXzlPk7gM72uVG166M12xgMIVYE/o1O+Hdazk=; Received: ; Tue, 13 Jun 2017 12:53:01 -0700 To: Phillip Hallam-Baker Cc: SPASM , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> From: Jacob Hoffman-Andrews Message-ID: <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> Date: Tue, 13 Jun 2017 12:53:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 13 Jun 2017 19:53:04 -0000 On 06/13/2017 10:04 AM, Phillip Hallam-Baker wrote: > So maybe reword to explicitly state that if we have a CNAME chain like > that, CAs may set a processing limit (provided they declare it) ? This works for me, but we should include a MUST with a minimum number of CNAMEs to follow, e.g. 10. From nobody Tue Jun 13 17:43: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 E5DD4127010 for ; Tue, 13 Jun 2017 17:43:01 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 8UTg7ZH5TnaP for ; Tue, 13 Jun 2017 17:43:00 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 5ADC9128BA2 for ; Tue, 13 Jun 2017 17:43:00 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5E0gX31029371; Wed, 14 Jun 2017 01:42:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Rk+GEBAOMp0xD09ZmzLolNXMWLamVVibbMsrP3JnOZ4=; b=WZTgFIUDNyaUL/z/TdIM77ckM5BygFyFrjGChlDjwIHdrYRcbtYgVMn4oeJFUgYvGUoH WNQ2j3XTXmKPb6cIpCspAy77Rgsgn/rG/2hxTD/98h5dl5W9pGI21+/IHfF/VXUGPCDo ZgQU6odpmS0SIYHZSuwVVRSs4w9KEc0p274V129nNQj6XieeLMNSMjZE2yPyvZoYK32T eQH/dm9EKbblA3oN5c8rf8S3M2PIdCWiqxXWCfyC3ZmWOf9wOd+Trj92nSec1yNiUYCY /StwE7Z4DdRTELGWMr0R0i0O17SEZvKyV2rb18trjElSvRA56ShRtQjPgN+HdczSBXuR Vg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2b2nb29tkk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 01:42:51 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5E0esJe017346; Tue, 13 Jun 2017 20:42:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3um3vy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 20:42:49 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 20:42:49 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 13 Jun 2017 20:42:49 -0400 From: "Salz, Rich" To: Jacob Hoffman-Andrews , Phillip Hallam-Baker CC: SPASM , Rob Stradling Thread-Topic: [lamps] [Spasm] Erratum 4988 Thread-Index: AQHS3ilYogFLC+R7ukilGRln4U1clKIXFg8AgAEMMwCAACcagIAK3YMAgAAnhACAAAaxgIAALvsAgAAN0yA= Date: Wed, 14 Jun 2017 00:42:48 +0000 Message-ID: <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> In-Reply-To: <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.194] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140010 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140011 Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 00:43:02 -0000 > > So maybe reword to explicitly state that if we have a CNAME chain like > > that, CAs may set a processing limit (provided they declare it) ? > This works for me, but we should include a MUST with a minimum number of > CNAMEs to follow, e.g. 10. Works for me. From nobody Tue Jun 13 18:31:06 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 87619129A96 for ; Tue, 13 Jun 2017 18:31:04 -0700 (PDT) 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 55_yarnkjqqs for ; Tue, 13 Jun 2017 18:31:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED5712947B for ; Tue, 13 Jun 2017 18:31:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D76337A3309; Wed, 14 Jun 2017 01:31:01 +0000 (UTC) Date: Wed, 14 Jun 2017 01:31:01 +0000 From: Viktor Dukhovni To: LAMPS Message-ID: <20170614013101.GC23375@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <149521958261.27235.13262265548463695364@ietfa.amsl.com> <50D23BF4-65DA-4895-B181-C4D0F2004E78@vigilsec.com> <20170607065351.GL22954@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [lamps] [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 01:31:04 -0000 On Mon, Jun 12, 2017 at 04:39:10PM -0400, Russ Housley wrote: > Your response implies that there is a second part to your review coming. > WG Last Call need last Friday. Please post any remains comments very soon > so that we can get an updated document. Yes, sorry, I'm on vacation, so time for review is limited, I'll try to have the second part out in the next ~24 hours. -- Viktor. From nobody Tue Jun 13 21:24: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 AF156131B00 for ; Tue, 13 Jun 2017 21:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=0.01] 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 tYlgZObp7msB for ; Tue, 13 Jun 2017 21:24:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DBA129B19 for ; Tue, 13 Jun 2017 21:24:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E4F017A3309; Wed, 14 Jun 2017 04:24:51 +0000 (UTC) Date: Wed, 14 Jun 2017 04:24:51 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170614042451.GD23375@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> <20170607045725.GI25754@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170607045725.GI25754@mournblade.imrryr.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: [lamps] draft-ietf-lamps-eai-addresses-10 full review Part 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 04:24:56 -0000 > 6. Name constraints in path validation > > This section updates [RFC5280] name constraints defined in section > 4.2.1.10 to work with SmtpUTF8Name subjectAltName. Better something along the lines of: This section updates section 4.2.1.10 of [RFC5280] to extend rfc822Name name constraints to SmtpUTF8Name subjectAltNames. > The following > specifies that a SmtpUTF8Name aware CA use a compatible name > constraint representation. What's a "compatible name constraint representation"? Either clarify or delete... > Similarly a SmtpUTF8Name aware path > validators MUST be able to apply name constraint comparison to the > subject distinguished name and both forms of subject alternative name > rfc822Name and SmtpUTF8Name. It is I think long past time to end support for extracting DNS-ID names and email email addresses from the certificate subject DN. We should consider updating 5280 to drop support for matching "emailAddress" in the subject DN when no rfc822name subject alternative names are present. If so, perhaps there should be no mention of enforcing email name constraints against the subject DN. Also, it is not clear what the "MUST" here means. It seems to me that this sentence is design rationale, not a protocol requirement. > The SmtpUTF8Name aware email address name constraint form is > specified to be rfc822Name motivated by compatibility considerations > with legacy systems that already understand that form. Better: Both rfc822Name and SmtpUTF8Name subject alternative names represent the same underlying email address namespace. Since legacy CAs constrained to issue certificates for a specific set of domains would lack corresponding UTF-8 constraints, this specification modifies and extends rfc822Name name constraints to cover SmtpUTF8Name subject alternative names. This ensures that the introduction of SmtpUTF8Name does not violate existing name constraints. > This > specification modifies [RFC5280] name constraint to only require with > MAY that it represents all addresses at a host or all mailboxes in a > domain, and require with MAY NOT that it represent a particular > mailbox. Better: Since it is not valid to include non-ASCII UTF-8 characters in the local-part of rfc822Name name constraints, and since name constraints that include a local-part are rarely, if at all, used in practice, this specification modifies [RFC5280] name constraints to only admit the forms represent all addresses at a host or all mailboxes in a domain, and deprecates rfc822Name name constraints that represent a particular mailbox. That is, rfc822Name constraints with a local-part MUST NOT be used. > For context, [RFC5280] Section 4.2.1.10 specifies with MAY > that name constraint represent a particular mailbox, all addresses at > a host, or all mailboxes in a domain by specifying the complete email > address, a host name, or a domain. The change is due to rfc822Name > name constraints inability to represent a specific mailbox with a > UTF-8 email local part email address. CA certificate issuers should > be aware of this lessened support. Delete. > Constraint comparison with SmtpUTF8Name subjectAltName starts with > the setup steps defined by Section 5. The setup applies to the > inputs of the comparison which is one of a subject distinguished name > or a rfc822Name or SmtpUTF8Name subjectAltName, and one of a > rfc822Name name constraint. Delete, and instead describe the actual process. > Non-normatively the setup will convert > any domain A-label to U-label in the rfc822Name name constraint, and > to lower case any domain NR-LDH label in both the name constraint and > the subject. Instead of "non-normatively", specify that comparison MUST be equivalent to: 0. CA certificates which include rfc822Name name constraints with a local-part are now invalid for issuing end-entity email certificates. Equivalently, such CA certificates now exclude all rfc822Name and SmtpUTF8Name subject alternative names in the end-entity certificate. 1. Strip the local-part and "@" separator from each rfc822Name and SmtpUTF8Name, leaving just the domain-part. 2. Decoding any A-labels in the rfc822Name name constraint to U-labels. 3. Converting any NR-LDH labels in the rfc822Name name constraint to lower case. 4. Decoding any A-labels in the domain-part of each rfc822Name or SmtpUTF8Name subject alternative name to U-labels. 5. Converting any NR-LDH labels in the domain-part of each rfc822Name or SmtpUTF8Name subject alternative name to lower case. 6. If the resulting name constraint domain starts with a "." character, then for the name constraint to match, a suffix of the resulting subject alternative name domain MUST match the name constraint (including the leading ".") octet for octet. 7. If the resulting name constraint domain does not start with a "." character, then for the name constraint to match, the entire resulting subject alternative name domain MUST match the name constraint octet for octet. > After setup, this follows the comparison steps defined > in 4.2.1.10 of [RFC5280] with some modifications as follows. The > comparison process starts by determining the name constraint > representation i.e. email host name or domain part, then comparing > the name constraint against the corresponding part in the email > address using a byte for byte comparison. This document suggests > that name constraint comparison with subject distinguished name or > rfc822Name subjectAltName also follow these setup and comparisons > steps as well. Delete. There should be some discussion of what CAs are expected to do when issuing constrained intermediate subsidiary CAs (accept only IDNA2008 conformant names with no mappings, converting to A-labels in rfc822Name subject alternative names and name constraints). > The name constraint requirement with SmtpUTF8Name subject alternative > name is illustrated in the non-normative diagram Figure 1. The first > example (1) illustrates a permitted rfc822Name ASCII only hostname > name constraint, and the corresponding valid rfc822Name > subjectAltName and SmtpUTF8Name subjectAltName email addresses. The > second example (2) illustrates a permitted rfc822Name hostname name > constraint with A-label, and the corresponding valid rfc822Name > subjectAltName and SmtpUTF8Name subjectAltName email addresses. > I would here re-iterate the requirement to use an A-label domain-part encoding in an rfc822Name subject alternative name when the local-part is all-ASCII. > +-------------------------------------------------------------------+ > | Root CA Cert | > +-------------------------------------------------------------------+ > v > +-------------------------------------------------------------------+ > | Intermediate CA Cert | > | Permitted | > | rfc822Name: elementary.school.example.com (1) | > | rfc822Name: xn--pss25c.example.com (2) | > +-------------------------------------------------------------------+ > v > +-------------------------------------------------------------------+ > | Entity Cert (w/explicitly permitted subjects) | > | SubjectAltName Extension | > | rfc822Name: student@elemenary.school.example.com (1) | > | SmtpUTF8Name: u+5B66u+751F@elementary.school.example.com (1) | > | | > | rfc822Name: student@xn--pss25c.example.com (2) | > | SmtpUTF8Name: u+533Bu+751F@u+5927u+5B66.example.com (2) | > +-------------------------------------------------------------------+ > > Name constraints with SmtpUTF8Name and rfc822Name > > Figure 1 > 7. Security Considerations > > Use for SmtpUTF8Name for certificate subjectAltName (and > issuerAltName) will incur many of the same security considerations of > Section 8 in [RFC5280] but is further complicated by permitting non- > ASCII characters in the email address local-part. s/Use for/Use of/ s/of Section 8/as in Section 8/ s/but is further complicated/, but introduces a new issue/ > This complication, > as mentioned in Section 4.4 of [RFC5890] and in Section 4 of > [RFC6532], is that use of Unicode introduces the risk of visually > similar and identical characters which can be exploited to deceive > the recipient. s/This complication/The issue/ -- Viktor. From nobody Wed Jun 14 12:03:32 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 478AF12EB01; Wed, 14 Jun 2017 12:03:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149746700325.13971.11163124597625126739@ietfa.amsl.com> Date: Wed, 14 Jun 2017 12:03:23 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5280-i18n-update-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 19:03:23 -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 : Internationalization Updates to RFC 5280 Author : Russ Housley Filename : draft-ietf-lamps-rfc5280-i18n-update-01.txt Pages : 8 Date : 2017-06-14 Abstract: These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5280-i18n-update-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5280-i18n-update-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5280-i18n-update-01 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 Wed Jun 14 12:04:38 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 D7B1612EB05 for ; Wed, 14 Jun 2017 12:04:37 -0700 (PDT) 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 UWN8MbJam36s for ; Wed, 14 Jun 2017 12:04:35 -0700 (PDT) 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 D3F4112EB01 for ; Wed, 14 Jun 2017 12:04:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2D24C3004D1 for ; Wed, 14 Jun 2017 15:04:35 -0400 (EDT) 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 sBwwOxlk33ok for ; Wed, 14 Jun 2017 15:04:34 -0400 (EDT) Received: from new-host-5.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2FE34300266 for ; Wed, 14 Jun 2017 15:04:34 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 14 Jun 2017 15:04:33 -0400 References: <149746700339.13971.7568072270168366217.idtracker@ietfa.amsl.com> To: LAMPS In-Reply-To: <149746700339.13971.7568072270168366217.idtracker@ietfa.amsl.com> Message-Id: <9D4549AE-40C6-4F09-B98B-FCF9857B61E4@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-rfc5280-i18n-update-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 19:04:38 -0000 I believe this update resolves all of the comments that were raised = during WG Last Call. Russ > On Jun 14, 2017, at 3:03 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-lamps-rfc5280-i18n-update-01.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-ietf-lamps-rfc5280-i18n-update > Revision: 01 > Title: Internationalization Updates to RFC 5280 > Document date: 2017-06-14 > Group: lamps > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5280-i18n-update-= 01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-rfc5280-i18n-update-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5280-i18n-update= -01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5280-i18n-update-0= 1 >=20 > Abstract: > These updates to RFC 5280 provide clarity on the handling of > Internationalized Domain Names (IDNs) and Internationalized Email > Addresses in X.509 Certificates. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Jun 14 12:14:11 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 53B46129487 for ; Wed, 14 Jun 2017 12:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR7dV-MOqZUF for ; Wed, 14 Jun 2017 12:14:08 -0700 (PDT) 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 F192A127869 for ; Wed, 14 Jun 2017 12:14:07 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id t7so3149042yba.3 for ; Wed, 14 Jun 2017 12:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4NMO35rOiFVORU83c5E/OFSnXzCbm5y+knLamo+Utfo=; b=xEDxqMjVimDheybyFwcZqhlQWsFkeiNI99rdMPTVeFXG2tqrd5RV2KbNYGECAm3wfr L2d15herJ6jUZMf3rZ19TtiZlYx4z9dVhPhyE3rZFQSWOfFFerJ5mW3WP7NHlJWu7IrK ls/FtkJtIvYUnEq0+QJh1gAyrvrgOuRZp3fQJoUM2p4fW2wdOhzreuVBf3JQ6mMrtNBg wM2FAUuTdQ+HNbC9dOUF9C4c+cTo3wsKq0BN0TYaX1BPhDOCG3WLjR2XOvgSWuo8Ltq8 gJs7spqy0ZScO+Ty2e1V9ldGpeFKcJniPVAUx1V6eiAypFQwY2etpHXcKGp7vsd5mGCP ZR8w== 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=4NMO35rOiFVORU83c5E/OFSnXzCbm5y+knLamo+Utfo=; b=mpEVP2Cnyxaa5zyVNGDvHC8gIa27xIzOcO8UNqAzHVt8bK1q8FunAeZKRIzqR0bhBU sVzqSTpgdrIFP90xx6y2hnenxflDmY3XrKwAta2biLUu/mMbR9lqnwDvMKtVOA/a686+ OXh+z6ouDMhDLgSFafoq+8zkgPuzl3CS9DdpDiKvHQO75JplQw3wXsAD7a2kdYIzXHSi 4VxnijJIDVVEKbjnqTvIFUOg8jg/hpQ0HH0FOSdiNotzJrfYqwoHUj8AYCXshkYwgMSh /LBrtWcoue1FzMifWKGChU51d1MTrXeVlLIkSgy1fAC7KiF+whv0hPOq8TaOaZSfdtcV 93Bw== X-Gm-Message-State: AKS2vOzsk0LKo53vExXmX/7RsSuaFHgEmPg8lp/UrEVF78Y3QUpLR7F3 DwfMDH6Qh/vX8n4EmKkLPer+MiYaRo8PP+0= X-Received: by 10.37.83.65 with SMTP id h62mr1389907ybb.92.1497467647176; Wed, 14 Jun 2017 12:14:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Wed, 14 Jun 2017 12:13:26 -0700 (PDT) In-Reply-To: <17DEEA39-10D0-4894-BD57-250E91835E7C@vigilsec.com> References: <17DEEA39-10D0-4894-BD57-250E91835E7C@vigilsec.com> From: Eric Rescorla Date: Wed, 14 Jun 2017 21:13:26 +0200 Message-ID: To: Russ Housley Cc: SPASM Content-Type: multipart/alternative; boundary="001a113e64502c63010551f05b7c" Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-rfc5280-i18n-update-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 19:14:09 -0000 --001a113e64502c63010551f05b7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This looks like consensus to me. Please pubreq when ready. -Ekr On Fri, May 26, 2017 at 9:39 PM, Russ Housley wrote: > This is the LAMPS WG Last Call for "Internationalization Updates to RFC > 5280=E2=80=9D . Please review t= he > document and send your comments to the list by 9 June 2017. > > Since I am the document author and the LAMPS WG Chair, our Area Director > will be making the consensus call at the end of the WG Last Call. > > Thanks, > Russ --001a113e64502c63010551f05b7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This looks like consensus to me. Please pubreq when ready.=

-Ekr


On Fri, May 26, 2017 at 9:39 PM, Russ Hou= sley <housley@vigilsec.com> wrote:
This is the LAMPS WG Last Call for "Internationalization= Updates to RFC 5280=E2=80=9D <draft-ietf-lamps-rfc5280-i18n-update= -00>.=C2=A0 Please review the document and send your comments to the lis= t by 9 June 2017.

Since I am the document author and the LAMPS WG Chair, our Area Director wi= ll be making the consensus call at the end of the WG Last Call.

Thanks,
Russ

--001a113e64502c63010551f05b7c-- From nobody Wed Jun 14 14:47: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 47DED129427 for ; Wed, 14 Jun 2017 14:47:45 -0700 (PDT) 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 I7ccoRZnBmeQ for ; Wed, 14 Jun 2017 14:47:43 -0700 (PDT) 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 388971243F3 for ; Wed, 14 Jun 2017 14:47:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A1D753004D1 for ; Wed, 14 Jun 2017 17:47:42 -0400 (EDT) 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 hGNZkA3jx4R2 for ; Wed, 14 Jun 2017 17:47:41 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9B20B3003FE for ; Wed, 14 Jun 2017 17:47:41 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 14 Jun 2017 17:47:41 -0400 To: LAMPS X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] Need shepherd for draft-ietf-lamps-rfc5280-i18n-update-01 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 21:47:45 -0000 I need someone that is willing to be the document shepherd for = draft-ietf-lamps-rfc5280-i18n-update-01. RFC 4858 explains the role. I started the shepherd write-up below. The template for the write-up = can be found here: = https://www.ietf.org/iesg/statement/document-shepherds.html Anyone willing to be the shepherd? Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D Shepherd Write-up for draft-ietf-lamps-rfc5280-i18n-update-01 (1) What type of RFC is being requested (BCP, Proposed Standard, = Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. Yes, the header calls for Standards Track. =20 This new RFC will update RFC 5280, which is a Proposed Standard. =20 (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document provides updates to RFC 5280 regarding the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. Working Group Summary: There is consensus for this document in the LAMPS WG. Document Quality: X.509 certificates are supported by many Certification Authorities and relying parties, especially browsers and S/MIME clients. Several implementers have said that they will implement the features in this document. Personnel: is the document shepherd. Eric Rescorla is the responsible area director. From nobody Wed Jun 14 15:38: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 0A7C612940D for ; Wed, 14 Jun 2017 15:38:38 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 4W7ZIGd7kWZb for ; Wed, 14 Jun 2017 15:38:36 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 7EB521293E8 for ; Wed, 14 Jun 2017 15:38:36 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5EMc2cN023549; Wed, 14 Jun 2017 23:38:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=J2nsNeTW+4gWdIvmFpiA6B8wqLNVfET5whUQm2vd+Hk=; b=dbVKzbFLuz+YNU9KY/MssMzZ1vwNOKlUj7SxBfwvEXEJ5Lc3KoNR7edkT7aSHuFD+rEh q6rz0n06AHvnXN1SolsuQartgcZC8CxSrTLGa9FImz9H3VlJu0P7HzbTxtq8bQM/iX0m PK3uOYnOu8AcBbQCn6Nut8Iiy/v4md5jZjxPmOzCtJbX/SYBliPd9fJf9HLRIkGXDPx9 Ojm9F5ZPXg6UeiBh9U5s7O2AQSAsreacwGd6PT2Nt6qSwGTkx4emh2Su7Sg02M6CapkB itNvX3Pfr8sPyMqsoNbGg2zGZTPcl6G5emtStmLj8fYN1uKHg2/MmrDHdEuh9zFyL2eh vA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b2ndvfwca-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 23:38:34 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5EMa2ns015968; Wed, 14 Jun 2017 18:38:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3ufe20-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 18:38:33 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Jun 2017 15:38:32 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 14 Jun 2017 18:38:32 -0400 From: "Salz, Rich" To: Russ Housley , LAMPS Thread-Topic: [lamps] Need shepherd for draft-ietf-lamps-rfc5280-i18n-update-01 Thread-Index: AQHS5VffTd8Ww4w4G0mcJFIr01YQ06Ik8yJg Date: Wed, 14 Jun 2017 22:38:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.79] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140374 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140375 Archived-At: Subject: Re: [lamps] Need shepherd for draft-ietf-lamps-rfc5280-i18n-update-01 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 22:38:38 -0000 > I need someone that is willing to be the document shepherd for draft-ietf= - > lamps-rfc5280-i18n-update-01. RFC 4858 explains the role. If nobody else wants it, I will. From nobody Wed Jun 14 16:07: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 623D5126C83 for ; Wed, 14 Jun 2017 16:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 QjB-UeTjHDYx for ; Wed, 14 Jun 2017 16:07:49 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 87898126579 for ; Wed, 14 Jun 2017 16:07:49 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id s7so11162170otb.3 for ; Wed, 14 Jun 2017 16:07:49 -0700 (PDT) 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=nhdMfVEQjRe45CRvr0s3d6n74Lz0No9jVzRsgjZRPPc=; b=ZDzHhCtFbZXcL21eL//qO3GqNwZIyk6Y7fIWsdeJiTB3Jky5wRfS1Qgc/LSpb7bu/+ 54qCXV+gS6NcOxfJa10Tvi8xl5Jwg22bjC1sfFaUvLnCVQoW++8Rcghnf42qEpFjNy+c vSPlx8nWBOEfS00YHO57VYT340HYRPX5B9qDnLtENFSViQA2OoRha12koQF0rfSr9Hbx DF/BmvLTt9aV831lwzYLbHNq5dX0Qk8lLeKBkKSpOl7+LmreRXEjjp5kfS4B2IVqZ4cb AqK8Xp/m7EADn/CCd1hXJ4F3cqg53Uayt2eKQ0YF0KnjnmJm0/4zZokgxNm/dVDU1v2T GgYA== 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=nhdMfVEQjRe45CRvr0s3d6n74Lz0No9jVzRsgjZRPPc=; b=DgpsVnAqOyUb4EcBFnY4guNqbkgIZZnyFgv9f2iBcSKDj5KF5SsvLtWPK0Yrj+u77a 1Rg6nwjMV6kcVC5ieJrjpZoLokbLjj4WSTk9YSPAQXYG4//no6KeCzATE28roZv3l8A9 H7G4W1I8b8yzAsJzHXjcDyJvq0KrKD6fNlDYjSbcOE57TopDm/AVbolaJqfGxP98Dy+8 mXJugKxpcBjMHYxeCqn09buhE+HMUqABXpLBhIxCBvadC4AzXnblPW7YvKbQOCwVOO4y 3+beBJlwcQjwQJSHvfBBXd6rvEIonOZcFO+i+bY6qobAFUgoz3AMVBbtaVeAT6vGqY30 Bl/g== X-Gm-Message-State: AKS2vOycBADcXmgJ5ZomogRm7LQwqmRGv0rBeYbMhW9BK2sUBD1ul4cp cjFTGNsXJyTo7MpItbPERjWyKi18YQ== X-Received: by 10.157.63.139 with SMTP id r11mr342934otc.28.1497481668835; Wed, 14 Jun 2017 16:07:48 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Wed, 14 Jun 2017 16:07:48 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 14 Jun 2017 19:07:48 -0400 X-Google-Sender-Auth: V_BIUuawgl35AhHy5Qp1TXhpHLU Message-ID: To: Russ Housley Cc: LAMPS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] Need shepherd for draft-ietf-lamps-rfc5280-i18n-update-01 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 23:07:51 -0000 I can do it. On Wed, Jun 14, 2017 at 5:47 PM, Russ Housley wrote: > I need someone that is willing to be the document shepherd for draft-ietf-lamps-rfc5280-i18n-update-01. RFC 4858 explains the role. > > I started the shepherd write-up below. The template for the write-up can be found here: https://www.ietf.org/iesg/statement/document-shepherds.html > > Anyone willing to be the shepherd? > > Russ > > = = = = = = = = = > > Shepherd Write-up for draft-ietf-lamps-rfc5280-i18n-update-01 > > > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the > proper type of RFC? Is this type of RFC indicated in the title page > header? > > Proposed Standard. Yes, the header calls for Standards Track. > > This new RFC will update RFC 5280, which is a Proposed Standard. > > > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: > > Technical Summary: > > This document provides updates to RFC 5280 regarding the handling of > Internationalized Domain Names (IDNs) and Internationalized Email > Addresses in X.509 Certificates. > > Working Group Summary: > > There is consensus for this document in the LAMPS WG. > > Document Quality: > > X.509 certificates are supported by many Certification Authorities > and relying parties, especially browsers and S/MIME clients. Several > implementers have said that they will implement the features in this > document. > > Personnel: > > is the document shepherd. > Eric Rescorla is the responsible area director. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Jun 14 16:11: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 AD3ED1270FC for ; Wed, 14 Jun 2017 16:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 ZUxEGxDOGo2E for ; Wed, 14 Jun 2017 16:11:12 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 C1DED126C83 for ; Wed, 14 Jun 2017 16:11:12 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id e11so9208814oia.2 for ; Wed, 14 Jun 2017 16:11:12 -0700 (PDT) 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=HOP6A8TRmV8PzXgeVlp3vfgrpRUsFO10kqbkRlWBPmk=; b=SF4dB04SsEmwXwuR0H4Wybwf0G+JBxLOFCPENSjJe3P4K5aChBpFrWZNmlFd18jKsC S+ynqMPupq7FuIvwWYEPF480YsaFyXh4y/aobYlt4ls4z1fZWew8XhmJq4Et3AD4mYKK PtAqK0ZlnLjP8HHP2RXna2OTZKXcXli0TO9Lbkf/9rzVtkzL5QI93r2hlOaiswXCuplq K2w3kIZo7v7XowcebzefFSEqx7q/Efu1Rm1b6Ri6GhRAf1zRy7Q7ssum7fFUHvSRuEJ5 sbxLr9OayPJVHoV08TtvwI3TdlmU8bq7wn+SVjZnKYkjYQAg+YkbO4ywxRqBGkvr/T7X FbVA== 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=HOP6A8TRmV8PzXgeVlp3vfgrpRUsFO10kqbkRlWBPmk=; b=fMb9O2C6lr2rD4cdT5lZEmn921u0m/826kt+DbzjZgNItjTip7dXd1HLEfaCWdgx0o bSjpitCYDCGznOhHenZygFmBy3IWnjEMRjwFLeLLxENfhujpYgcKS1lsRW1zMWJZngrx rNbetIHwzWAnqeh99Xk82ZnSL0rzv4cpTBRYEUPfFelOo3e8qOAS40cj33PKed9tJuHf 6h8gFDjGEdV0RVFUnceI/ceT3IhcKtI3gpjMx8SrhPNP7cDJpYRRDncFBPIwhLWng4Hc Ebu0jSy4nZDnlmQvw9r57tfRBLFxJfsTz2pBam9/7vpZWBIUO9rxoL26iSTsKvyj1hlZ t6zQ== X-Gm-Message-State: AKS2vOy8LCo8U8bxvIczvuM1/k+39RVYmAalVfJSjMqtBvcfYMYU2Lg8 OPKDKMaPmFixGMuvhd4prnBlzhiZxQ== X-Received: by 10.202.235.12 with SMTP id j12mr1495276oih.2.1497481872132; Wed, 14 Jun 2017 16:11:12 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Wed, 14 Jun 2017 16:11:11 -0700 (PDT) In-Reply-To: <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Wed, 14 Jun 2017 19:11:11 -0400 X-Google-Sender-Auth: ed8-snqDnXFQ2yggObSIA4uMVhE Message-ID: To: "Salz, Rich" Cc: Jacob Hoffman-Andrews , SPASM , Rob Stradling Content-Type: multipart/alternative; boundary="001a113cc70c0bfcbb0551f3ab1e" Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jun 2017 23:11:15 -0000 --001a113cc70c0bfcbb0551f3ab1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The RFC Editor has deleted all three of the existing errata. I would like for the next errata to be the very last. Could people read, review and state if this works for them? =E2=80=8B This text is the same as the one I posted to CABForum earlier wit= h the one exception being that I capitalized Otherwise in the place it needed it.= =E2=80=8B Original Text ------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record specified at the label X. o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise o If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D R(A(X)), otherwise o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise o R(X) is empty. Corrected Text -------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record chain specified at the label X. o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D CAA(A(X)), otherwise o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise o R(X) is empty. Thus, when a search at node X returns a CNAME record, the CA will follow the CNAME record to its target. If the target label contains a CAA record, it is returned. =E2=80=8BO=E2=80=8B therwise, the CA continues the search at the parent of node X. Note that the search does not include the parent of a target of a CNAME record (except when the CNAME points back to its own path). To prevent resource exhaustion attacks, CAs should limit the length of CNAME chains that are accepted. However CAs MUST process CNAME chains that contain ten or fewer CNAME records. Processing for DNAME is exactly the same as for CNAME. Note that since DNAME records are implemented by creating the corresponding CNAME records on the fly, it is only necessary for DNAME records to appear on the wire for purposes of DNSSEC. --001a113cc70c0bfcbb0551f3ab1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The RFC Editor has deleted all three of the= existing errata. I would like for the next errata to be the very last.

=C2= =A0

= Could people read, review and state if this works for them?

=E2=80=8B This = text is the same as the one I posted to CABForum earlier with the one excep= tion being that I capitalized Otherwise in the place it needed it.=E2=80=8B=


=C2=A0

Original Text

-------------

=C2=A0=C2=A0 Let CAA(X) be = the record set returned in response to performing a CAA

=C2=A0=C2=A0 recor= d query on the label X, P(X) be the DNS label immediately above

=C2=A0=C2= =A0 X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

=C2= =A0=C2=A0 alias record specified at the label X.

=C2=A0

=

=C2=A0=C2=A0 o= =C2=A0 If CAA(X) is not empty, R(X) =3D CAA (X), otherwise

=C2=A0

=C2=A0= =C2=A0 o=C2=A0 If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D=

=C2=A0

=C2=A0=C2=A0 o= =C2=A0 If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise<= /u>

= =C2=A0

=C2=A0=C2=A0 o=C2=A0 R(X) is empty.

=C2=A0

=C2=A0

Corrected Text

=

--------------

= =C2=A0=C2=A0 Let CAA(X) be the record set returned in response to performin= g a CAA

=C2=A0=C2=A0 record query on the label X, P(X) be the DNS label im= mediately above

=C2=A0=C2=A0 X in the DNS hierarchy, and A(X) be the targe= t of a CNAME or DNAME

=C2=A0=C2=A0 alias record chain specified at the lab= el X.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If CAA(X) is not empty, R(X) =3D CAA (X= ), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If A(X) is not null, and CAA(A(X= )) is not empty, then R(X) =3D

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CAA(A(X)), o= therwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If X is not a top-level domain, then= R(X) =3D R(P(X)), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 R(X) is empty.

= =C2=A0

=C2=A0 Thus, when a search at node X returns a CNAME record, the CA= will

=C2=A0 follow the CNAME record to its target. If the target label co= ntains a

=C2=A0 CAA record, it is returned.

=E2=80=8BO=E2=80=8B
therwi= se, the CA continues the search at

=C2=A0 the parent of node X.<= u>

=C2=A0

=C2=A0 CNAME record (except when the CNAME points back to its own path).

= =C2=A0

=C2=A0To prevent resource exhaustion attacks, CAs should limit the = length of

=C2=A0=C2=A0CNAME chains that are accepted. However CAs MUST pro= cess CNAME

=C2=A0=C2=A0chains that contain ten or fewer CNAME records.<= /u>

= =C2=A0

=C2=A0 Processing for DNAME is exactly the same as for CNAME. Note = that since

=C2=A0 DNAME records are implemented by creating the correspond= ing CNAME

=C2=A0 records on the fly, it is only necessary for DNAME record= s to appear

=C2=A0 on the wire for purposes of DNSSEC.

--001a113cc70c0bfcbb0551f3ab1e-- From nobody Thu Jun 15 08:12:06 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 24C2F12EAA6 for ; Thu, 15 Jun 2017 08:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Wy0LDsv_4a5G for ; Thu, 15 Jun 2017 08:12:03 -0700 (PDT) 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 08E2E12957C for ; Thu, 15 Jun 2017 08:12:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 57D773004D0 for ; Thu, 15 Jun 2017 11:12:02 -0400 (EDT) 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 boMbEO02nAxW for ; Thu, 15 Jun 2017 11:12:00 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C88A630002C; Thu, 15 Jun 2017 11:12:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Thu, 15 Jun 2017 11:12:03 -0400 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: <1CE3BA40-7416-4D82-9612-014E683A42AA@vigilsec.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Need shepherd for draft-ietf-lamps-rfc5280-i18n-update-01 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jun 2017 15:12:05 -0000 Thanks. > On Jun 14, 2017, at 7:07 PM, Phillip Hallam-Baker = wrote: >=20 > I can do it. >=20 > On Wed, Jun 14, 2017 at 5:47 PM, Russ Housley = wrote: >> I need someone that is willing to be the document shepherd for = draft-ietf-lamps-rfc5280-i18n-update-01. RFC 4858 explains the role. >>=20 >> I started the shepherd write-up below. The template for the write-up = can be found here: = https://www.ietf.org/iesg/statement/document-shepherds.html >>=20 >> Anyone willing to be the shepherd? >>=20 >> Russ >>=20 >> =3D =3D =3D =3D =3D =3D =3D =3D =3D >>=20 >> Shepherd Write-up for draft-ietf-lamps-rfc5280-i18n-update-01 >>=20 >>=20 >> (1) What type of RFC is being requested (BCP, Proposed Standard, = Internet >> Standard, Informational, Experimental, or Historic)? Why is this the >> proper type of RFC? Is this type of RFC indicated in the title page >> header? >>=20 >> Proposed Standard. Yes, the header calls for Standards Track. >>=20 >> This new RFC will update RFC 5280, which is a Proposed Standard. >>=20 >>=20 >> (2) The IESG approval announcement includes a Document Announcement >> Write-Up. Please provide such a Document Announcement Write-Up. = Recent >> examples can be found in the "Action" announcements for approved >> documents. The approval announcement contains the following = sections: >>=20 >> Technical Summary: >>=20 >> This document provides updates to RFC 5280 regarding the handling = of >> Internationalized Domain Names (IDNs) and Internationalized Email >> Addresses in X.509 Certificates. >>=20 >> Working Group Summary: >>=20 >> There is consensus for this document in the LAMPS WG. >>=20 >> Document Quality: >>=20 >> X.509 certificates are supported by many Certification Authorities >> and relying parties, especially browsers and S/MIME clients. = Several >> implementers have said that they will implement the features in = this >> document. >>=20 >> Personnel: >>=20 >> is the document shepherd. >> Eric Rescorla is the responsible area director. >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Jun 19 12:51:36 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 D9AD0129463 for ; Mon, 19 Jun 2017 12:51:32 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 Opy-pbRj2iFg for ; Mon, 19 Jun 2017 12:51:29 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 48652128954 for ; Mon, 19 Jun 2017 12:51:29 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m62so1968111itc.0 for ; Mon, 19 Jun 2017 12:51:29 -0700 (PDT) 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=7SmKnhbAe22cUEeQXWRUWqDcO6ayLJpFNnlTr+Zq7WM=; b=kxswbaQkkrwWrFtQQOmgjRhxNJIzWBxV9VP2k9dffckGZcY4AvpRoETyPUC9uRxJNZ r8KrePuIeHuCqgIhmcq8Pg9ktZ8ck8hovmD83dMY7iZaHUxKmFHFQtbTIDCLZOruuOzr uozZOAbs3R+uHFfDAx2x74W0AGwIrdheIch/oNBOY5Jearq4GaYX+d7qvei2TvcO8bP7 R+IEIFtiS84+JiX1a+uSHd9M105QBYa761ZWgQ0/XpLajYJxQOlnY6M9Ac0Vpqlv/URc GqUkNIUvdHn63olpJXyvWV+UcAla65SQfGkaLqWdUvf0ytydobvHXF0slUg7hyhN/T1f vlpQ== 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=7SmKnhbAe22cUEeQXWRUWqDcO6ayLJpFNnlTr+Zq7WM=; b=Qmt2di2mbuiDhRXJUrtE9Qm46fK8fEO9BmpoyGo+mySpq8PqE4TG4eX+NcOS2jaeF5 XsMnVLsy55ECmux0daTirHFbxM+z3faMXPLNdJElaHiyU2ooCk7Pkb42pPzVBzz+JQgO cAIp7GqDIv0Q2GbIsuTlaaI3eQ59LcMla/wX4upPwNl7OOursUmQV5xLs/tmdn9CwMdQ ILwIR5t4rsUSK8cMK8WnUCd9oso4Zr/QZmN8AUGMxdFz6PwLUg+pQycb8z8v9g4iUfx9 poF0N0fSdZzB3xgmgyxooZI9IQQrvEsh9A8ggSwqoD07d/tzzzlwN+/yaYP3Kk3/o8Tn Tzag== X-Gm-Message-State: AKS2vOwFpjmhgp23UACfej6VZiDNk1yRQuzmAJSX1Gu9B3AUFnR2iViJ 8Np4fkmIzVzUNpP80jAIUaCbkL+R/5KZ4eE= X-Received: by 10.36.160.75 with SMTP id o72mr360839ite.119.1497901888087; Mon, 19 Jun 2017 12:51:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.170.142 with HTTP; Mon, 19 Jun 2017 12:51:27 -0700 (PDT) In-Reply-To: <20170607045725.GI25754@mournblade.imrryr.org> References: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> <20170607045725.GI25754@mournblade.imrryr.org> From: Wei Chuang Date: Mon, 19 Jun 2017 12:51:27 -0700 Message-ID: To: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c03d38cfc1f7c0552557501" Archived-At: Subject: Re: [lamps] draft-ietf-lamps-eai-addresses-10 full review Part 1 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 19:51:33 -0000 --94eb2c03d38cfc1f7c0552557501 Content-Type: multipart/alternative; boundary="94eb2c03d38cf338050552557580" --94eb2c03d38cf338050552557580 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Part 2 to follow. On Tue, Jun 6, 2017 at 9:57 PM, Viktor Dukhovni wrote: > On Fri, May 26, 2017 at 03:37:07PM -0400, Russ Housley wrote: > > > This is the LAMPS WG Last Call for "Internationalized Email Addresses i= n > > X.509 Certificates=EF=BF=BD . Pleas= e review > > the document and send your comments to the list by 9 June 2017. > > See below. > > > 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. > > s/Issuer Alternate Name/Issuer Alternative Name/ Done. > > Is there actually a use-case for EAI email addresses in issuer > alternative names? Are issuer alternative names used at all? > Russ called for including this during in one of the earlier edits comment period. > > > 1. Introduction > > > > [RFC5280] defines rfc822Name subjectAltName choice for representing > > s/rfc822Name subjectAltName choice/the rfc822Name subjectAltName name > type/ Done > > > [RFC5321] email addresses. This form is restricted to a subset of > > s/This form/The syntax of rfc822Name/ > Done > > > US-ASCII characters and thus can't be used to represent > > Internationalized Email addresses [RFC6531]. To facilitate use of > > these Internationalized Email addresses with X.509 certificates, thi= s > > s/these// > Done > > > document specifies a new name form in otherName so that > > subjectAltName and issuerAltName can carry them. In addition this > > s/a new name form in otherName/a new otherName variant/ > Done > s/so that subjectAltName and issuerAltName can carry them// > Done > > > document calls for all email address domain in X.509 certificates to > > conform to IDNA2008 [RFC5890]. > > s/domain/domains/ > Done > s/conform to IDNA2008 [RFC5890]/conform to IDNA2008 [RFC5890], wi= th > non-ASCII domains encoded in A-label form/ > This turn out to be confusing though correct. I haven't added this. > > > 3. Name Definitions > > > > The GeneralName structure is defined in [RFC5280], and supports many > > different names forms including otherName for extensibility. This > > s/names forms/name forms/ > Done > > > section specifies the SmtpUTF8Name name form of otherName, so that > > Given that email certificates pertain (primarily) to email messages > and not email transport, perhaps SmtpUTF8Name is not the best term > to introduce here? It is likely too late to suggest "UTF8MailboxName", > but if not, it is clear and removes the out of place connection to SMTP. > The original name for this type was eaiName which is close to what you're suggesting. There was a suggestion that this type is tied to email header addresses and that name this SmtpUTF8. I'd agree that its late now to rehash a new name type. > > > Internationalized Email addresses can appear in the subjectAltName o= f > > a certificate, the issuerAltName of a certificate, or anywhere else > > that GeneralName is used. > > Well, not really *anywhere* else, since we're specifically excluding > this name type in the context of name constraints. And it seems quite > unlikely that it will appear anywhere other than as a subjectAltName. > The original document just only specified subjectAltName. Russ Housley suggested including issuerAltName to be thorough. > > > When the subjectAltName (or issuerAltName) extension contains an > > Internationalized Email address, the address MUST be stored in the > > SmtpUTF8Name name form of otherName. The format of SmtpUTF8Name is > > But addresses with an all-ASCII localpart and a non-ASCII domain will > be stored via rfc822Name with the domainpart converted to A-label form. > So the above is perhaps misleading... > Done > > > defined as the ABNF rule SmtpUTF8Mailbox. SmtpUTF8Mailbox is a > > modified version of the Internationalized Mailbox which was defined > > in Section 3.3 of [RFC6531] which was itself derived from SMTP > > Mailbox from Section 4.1.2 of [RFC5321]. [RFC6531] defines the > > following ABNF rules for Mailbox whose parts are modified for > > internationalization: , , , > > , , and . In particular, > > was updated to also support UTF8-non-ascii. UTF8-non-ascii was > > described by Section 3.1 of [RFC6532]. Also, sub-domain was extende= d > > to support U-label, as defined in [RFC5890]. > > This too seems to invite a name that is more like "UTF8MailboxName" than > "SmtpUTF8Name". > > Instead of trying to import the ABNF from multiple documents, which > in turn import ABNF from yet more documents, ... It is perhaps time > to consolidate the relevant definitions in place, with a single > set of named building blocks. > > > This document further refines Internationalized [RFC6531] Mailbox > > ABNF rules and calls this SmtpUTF8Mailbox. > > If not too late: s/SmtpUTF8Mailbox/UTF8Mailbox/ > Alas, see above. > > > In SmtpUTF8Mailbox, sub- > > domain that encode non-ASCII characters SHALL use U-label Unicode > > native character labels and MUST NOT use A-label [RFC5890]. > > What appears to be meant by "sub-domain" here is in fact a label. > It would be more clear to avoid additional terminology for the same > thing. And why "encode"? Better would be: > > In SmtpUTF8Mailbox, > labels that include non-ASCII characters MUST be stored in > U-label (rather than A-label) [RFC5890] form. > Done > > > This > > restriction prevents having to determine which label encoding A- or > > U-label is present in the Domain. > > s/prevents/removes the need/ > Done > > > As per Section 2.3.2.1 of > > [RFC5890], U-label use UTF-8 [RFC3629] with Normalization Form C and > > other properties specified there. > > s/U-label use/U-labels are encoded as/ > Done > s/with/in/ > Done > > > In SmtpUTF8Mailbox, sub-domain > > that encode ASCII character labels SHALL use NR-LDH restrictions as > > specified by section 2.3.1 of [RFC5890] and SHALL be restricted to > > lower case letters. > > s/sub-domain/domains/ > Done > s/encode/include/ > Done > > It is not clear what the above is saying. Is it talking about > all-ASCII labels? Yes. > Or ASCII characters generally, possibly in > U-labels? ASCII + UTF8 would interpret that as a U-label > What are "NR-LDH restrictions"? I did not see any such > term defined in rfc5890. What is defined is "NR-LDH label" (2.3.2.2). > The reference is for section 2.3.1. There NR-LDH stands for Non-Reserved Letters Digits Hyphen which is intended to exclude A-label and like encodings. I've spelled out NR-LDH and make mention of the intent. > > > One suggested approach to apply these sub- > > domains restriction is to restrict sub-domain so that labels not > > start with two letters followed by two hyphen-minus characters. > > This makes no sense at all, and should probably be removed. > I've tried to clean up the intent here, which is to say that two > > > Consistent with the treatment of rfc822Name in [RFC5280], > > SmtpUTF8Name is an envelope and has no phrase (such as a > > common name) before it, has no comment (text surrounded in > > parentheses) after it, and is not surrounded by "<" and ">". > > Surely there's no need to drag in any mention of envelopes. It seems there is IETF history here on envelope vs RFC822 email addresses, and rather than revisit this, this document tries keeps the intent of the rfc822Name as precedence. > If there is no ABNF construct elsewhere that gives just the desired > address part, define it here. Trying to use ABNF by reference > makes this document contorted and unclear. > I think the intent is more clear adopting existing ABNF. What do other folks think? > > Due to operational reasons described shortly and name constraint > > s/described/to be described/ > Done > > > compatibility reasons described in its section, > > s/its section// > Done > > > SmtpUTF8Name > > subjectAltName MUST only be used when the local part of the email > > address contains UTF-8. > > UTF-8 is an encoding, not content: > > s/containts UTF-8/contains non-ASCII characters/ > Done > > > When the local-part is ASCII, rfc822Name > > subjectAltName MUST be used instead of SmtpUTF8Name. The use of > > rfc822Name rather than SmtpUTF8Name is currently more likely to be > > supported. > > The second sentence would be better as: > > This is compatible with legacy software that supports only > rfc822Name (and not SmtpUTF8Name). > Done > > > Also use of SmtpUTF8Name incurs higher byte > > representation overhead due to encoding with otherName and the > > additional OID needed. This may be offset if domain requires non- > > ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name > > supports A-label. > > This is not sufficiently compelling to be mentioned. Please remove. Done > > > 4. IDNA2008 > > > > To facilitate comparison between email addresses, all email address > > domain in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and > > excludes any "mappings" mentioned in that document). > > s/domain/domains/ > Done > s/excludes/avoid/ > Done > > > Otherwise non- > > conforming email address domains introduces the possibility of > > conversion errors between alternate forms. > > s/Otherwise/Use of/ > > Done > > This applies to > > SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName and > > anywhere else that GeneralName is used. > > s/SmtpUTF8Mailbox/SmtpUTF8Name/ > Done > s/GeneralName is/these are/ > Done > > > 5. Matching of Internationalized Email Addresses in X.509 certificates > > > > In equivalence comparison with SmtpUTF8Name, there may be some setup > > work to enable the comparison i.e. processing of the SmtpUTF8Name > > content or the email address that is being compared against. > > This is a lot of words to say very little or nothing at all. Delete > or clarify. > Done > > > The > > process for setup for comparing with SmtpUTF8Name is split into > > domain steps and local- part steps. > > The phrase "process for setup for comparing" is exceedingly convoluted, > please fix. How about just: "Comparing SmtpUTF8Names consists of a > domain-part step and a local-part step". > Done > > > The comparison form for local- > > part always is UTF-8. The comparison form for domain depends on > > context. > > s/local-part/local-parts/ > Done > s/domain/domain-parts/ > Done > > > Comparison of two SmtpUTF8Name is straightforward with no setup work > > needed. They are considered equivalent if there is an exact octet- > > for-octet match. > > What is expected to be compared are not two "SmtpUTF8Name" objects, but such an object with an email address, or such an object with > an rfc822Name constraint. And, with NR-LDH labels, case insensitive > comparison may be required. Enforcing insensitivity is done by lower casing the NR-LDH labels mentioned in Section 3. > Why are we descibing comparisons that > don't happen? > Agreed but as you point out out next there are a number of scenarios. As you mention, this is meant to cover SmtpUTF8Name comparison to EAI header email address, and comparison of certificate to certificate whose email addresses may be in three different forms. This intentionally looks for content differences (as opposed to format differences) to be sure there is in fact a difference. > > > Comparison with other email address forms such as > > SmtpUTF8Name is not an "email address form", it is a GeneralName form. > So "other email address forms" is not correct. > Changed to "Comparison with email addresses" > > > Internationalized email address or rfc822Name requires additional > > setup steps. Domain setup is particularly important for forms that > > may contain A- or U-label such as International email address, or > > A-label only forms such as rfc822Name. > > Clarify or delete. > Simplified. > > > This document specifies the > > process to transform the domain to U-label. (To convert the domain > > to A-label, follow the process specified in section 7.5 and 7.2 in > > [RFC5280]) > > Why the parenthetical comment? This serves two purposes- 1) points to a A-label normalization form setup in case that's desired 2) documents the 5280 normalization. The later is the only part that I believe is necessary. I see your point about confusion, so I've pull the reference into the previous paragraph where it acts as a more specific reference. > And we don't specify the process > of transforming to U-label form. Rather we require such conversion > when one of the addresses being compared employs A-labels. > > > > The first step is to detect A-label by using section 5.1 > > of [RFC5891]. > > s/A-label/use of A-labels/ > Done > > > Next if necessary, transform the A-label to U-label > > Unicode as specified in section 5.2 of [RFC5891]. Finally if > > necessary convert the Unicode to UTF-8 as specified in section 3 of > > [RFC3629]. > > s/the A-label/any A-labels/ > Done > s/U-label/U-labels/ > Done > > Nobody will convert to UTF-8 in two separate steps. In practice > a library will be used that converts from A-label form to UTF-8 > encoded Unicode. > > > For ASCII NR-LDH labels, upper case letters are converted > > to lower case letters. > > Fine. > > > In setup for SmtpUTF8Mailbox, the email > > address local-part MUST conform to the requirements of [RFC6530] and > > [RFC6531], including being a string in UTF-8 form. In particular, > > Given the below, I don't see any need for the above. > An earlier review comment requested citing those documents to provide context. > > > the local-part MUST NOT be transformed in any way, such as by doing > > case folding or normalization of any kind. The part of > > an Internationalized email address is already in UTF-8. > > > To summarize non-normatively, the comparison steps including setup > > are: > > > > 1. If the domain contains A-labels, transform them to U-label. > > s/U-label/U-labels/ > Done > > > 2. If the domain contains ASCII NR-LDH labels, lowercase them. > > > > 3. Ensure local-part is UTF-8. > > Since the local-part of email addressees is not accompanied by any > encoding information, it is *presumptively* UTF-8, and there is > nothing to do (or that can be done) in this step. > Done > > > 4. Compare strings octet-for-octet for equivalence. > > > This specification expressly does not define any wildcards character= s > > s/wildcards/wildcard/ > Done > > > and SmtpUTF8Name comparison implementations MUST NOT interpret any > > character as wildcards. Instead, to specify multiple email addresse= s > > through SmtpUTF8Name, the certificate SHOULD use multiple > > s/SHOULD/MUST/ > Done > > > subjectAltNames or issuerAltNames to explicitly carry those email > > addresses. > > s/those/any additional/ > > More to follow. > > -- > Viktor. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --94eb2c03d38cf338050552557580 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Part 2 to follow.

On Tue, Jun 6, 2017 at 9:57 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Fri, May 26, 2017 at 03:37:07PM -0400, Russ Hous= ley wrote:

> This is the LAMPS WG Last Call for "Internationalized Email Addre= sses in
> X.509 Certificates=EF=BF=BD <draft-ietf-lamps-eai-addresses-10= >.=C2=A0 Please review
> the document and send your comments to the list by 9 June 2017.

See below.

>=C2=A0 =C2=A0 This document defines a new name form for inclusion in th= e otherName
>=C2=A0 =C2=A0 field of an X.509 Subject Alternative Name and Issuer Alt= ernate Name
>=C2=A0 =C2=A0 extension that allows a certificate subject to be associa= ted with an
>=C2=A0 =C2=A0 Internationalized Email Address.

=C2=A0 =C2=A0 s/Issuer Alternate Name/Issuer Alternative Name/=C2=A0

Done.
=C2=A0

Is there actually a use-case for EAI email addresses in issuer
alternative names?=C2=A0 Are issuer alternative names used at all?

Russ called for including this during in one of= the earlier edits comment period.
=C2=A0

> 1.=C2=A0 Introduction
>
>=C2=A0 =C2=A0 [RFC5280] defines rfc822Name subjectAltName choice for re= presenting

=C2=A0 =C2=A0 s/rfc822Name subjectAltName choice/the rfc822Name subjectAltN= ame name type/

Done
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0
=C2=A0

>=C2=A0 =C2=A0 [RFC5321] email addresses.=C2=A0 This form is restricted = to a subset of

=C2=A0 =C2=A0 s/This form/The syntax of rfc822Name/
Done
=C2=A0

>=C2=A0 =C2=A0 US-ASCII characters and thus can't be used to represe= nt
>=C2=A0 =C2=A0 Internationalized Email addresses [RFC6531].=C2=A0 To fac= ilitate use of
>=C2=A0 =C2=A0 these Internationalized Email addresses with X.509 certif= icates, this

=C2=A0 =C2=A0 s/these//

Done
= =C2=A0

>=C2=A0 =C2=A0 document specifies a new name form in otherName so that >=C2=A0 =C2=A0 subjectAltName and issuerAltName can carry them.=C2=A0 In= addition this

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/a new name form in otherName/a new otherName = variant/

Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/so that subjectAltName and issuerAltName can = carry them//

Done
=C2=A0

>=C2=A0 =C2=A0 document calls for all email address domain in X.509 cert= ificates to
>=C2=A0 =C2=A0 conform to IDNA2008 [RFC5890].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/domain/domains/

Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/conform to IDNA2008 [RFC5890]/conform to IDNA= 2008 [RFC5890], with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 non-ASCII domains encoded in A-label for= m/

This turn out to be confusing though= correct.=C2=A0 I haven't added this.
=C2=A0

> 3.=C2=A0 Name Definitions
>
>=C2=A0 =C2=A0 The GeneralName structure is defined in [RFC5280], and su= pports many
>=C2=A0 =C2=A0 different names forms including otherName for extensibili= ty.=C2=A0 This

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/names forms/name forms/
=
Done
=C2=A0

>=C2=A0 =C2=A0 section specifies the SmtpUTF8Name name form of otherName= , so that

Given that email certificates pertain (primarily) to email messages
and not email transport, perhaps SmtpUTF8Name is not the best term
to introduce here?=C2=A0 It is likely too late to suggest "UTF8Mailbox= Name",
but if not, it is clear and removes the out of place connection to SMTP.

The original name for this type was eaiNa= me which is close to what you're suggesting.=C2=A0 There was a suggesti= on that this type is tied to email header addresses and that name this Smtp= UTF8.=C2=A0 I'd agree that its late now to rehash a new name type.
=C2=A0

>=C2=A0 =C2=A0 Internationalized Email addresses can appear in the subje= ctAltName of
>=C2=A0 =C2=A0 a certificate, the issuerAltName of a certificate, or any= where else
>=C2=A0 =C2=A0 that GeneralName is used.

Well, not really *anywhere* else, since we're specifically excluding this name type in the context of name constraints.=C2=A0 And it seems quite=
unlikely that it will appear anywhere other than as a subjectAltName.

The original document just only specified su= bjectAltName.=C2=A0 Russ Housley suggested including issuerAltName to be th= orough.
=C2=A0

>=C2=A0 =C2=A0 When the subjectAltName (or issuerAltName) extension cont= ains an
>=C2=A0 =C2=A0 Internationalized Email address, the address MUST be stor= ed in the
>=C2=A0 =C2=A0 SmtpUTF8Name name form of otherName.=C2=A0 The format of = SmtpUTF8Name is

But addresses with an all-ASCII localpart and a non-ASCII domain will
be stored via rfc822Name with the domainpart converted to A-label form.
So the above is perhaps misleading...

D= one
=C2=A0

>=C2=A0 =C2=A0 defined as the ABNF rule SmtpUTF8Mailbox.=C2=A0 SmtpUTF8M= ailbox is a
>=C2=A0 =C2=A0 modified version of the Internationalized Mailbox which w= as defined
>=C2=A0 =C2=A0 in Section 3.3 of [RFC6531] which was itself derived from= SMTP
>=C2=A0 =C2=A0 Mailbox from Section 4.1.2 of [RFC5321].=C2=A0 [RFC6531] = defines the
>=C2=A0 =C2=A0 following ABNF rules for Mailbox whose parts are modified= for
>=C2=A0 =C2=A0 internationalization: <Local-part>, <Dot-string&= gt;, <Quoted-string>,
>=C2=A0 =C2=A0 <QcontentSMTP>, <Domain>, and <Atom>.= =C2=A0 In particular, <Local-part>
>=C2=A0 =C2=A0 was updated to also support UTF8-non-ascii.=C2=A0 UTF8-no= n-ascii was
>=C2=A0 =C2=A0 described by Section 3.1 of [RFC6532].=C2=A0 Also, sub-do= main was extended
>=C2=A0 =C2=A0 to support U-label, as defined in [RFC5890].

This too seems to invite a name that is more like "UTF8MailboxName&quo= t; than
"SmtpUTF8Name".

Instead of trying to import the ABNF from multiple documents, which
in turn import ABNF from yet more documents, ...=C2=A0 It is perhaps time to consolidate the relevant definitions in place, with a single
set of named building blocks.

>=C2=A0 =C2=A0 This document further refines Internationalized [RFC6531]= Mailbox
>=C2=A0 =C2=A0 ABNF rules and calls this SmtpUTF8Mailbox.

If not too late:=C2=A0 s/SmtpUTF8Mailbox/UTF8Mailbox/
=
Alas, see above.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 In SmtpUTF8Mailbox, sub-
>=C2=A0 =C2=A0 domain that encode non-ASCII characters SHALL use U-label= Unicode
>=C2=A0 =C2=A0 native character labels and MUST NOT use A-label [RFC5890= ].

What appears to be meant by "sub-domain" here is in fact a label.=
It would be more clear to avoid additional terminology for the same
thing.=C2=A0 And why "encode"?=C2=A0 Better would be:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0In SmtpUTF8Mailbox,
=C2=A0 =C2=A0 =C2=A0labels that include non-ASCII characters MUST be stored= in
=C2=A0 =C2=A0 =C2=A0U-label (rather than A-label) [RFC5890] form.

Done
=C2=A0

>=C2=A0 =C2=A0 This
>=C2=A0 =C2=A0 restriction prevents having to determine which label enco= ding A- or
>=C2=A0 =C2=A0 U-label is present in the Domain.

=C2=A0 =C2=A0 s/prevents/removes the need/

<= div>Done
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As per= Section 2.3.2.1 of
>=C2=A0 =C2=A0 [RFC5890], U-label use UTF-8 [RFC3629] with Normalization= Form C and
>=C2=A0 =C2=A0 other properties specified there.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/U-label use/U-labels are encoded as/

Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/with/in/

= Done
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In Smt= pUTF8Mailbox, sub-domain
>=C2=A0 =C2=A0 that encode ASCII character labels SHALL use NR-LDH restr= ictions as
>=C2=A0 =C2=A0 specified by section 2.3.1 of [RFC5890] and SHALL be rest= ricted to
>=C2=A0 =C2=A0 lower case letters.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/sub-domain/domains/

=
Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/encode/include/

Done
=C2=A0

It is not clear what the above is saying.=C2=A0 Is it talking about
all-ASCII labels?

Yes.
=C2=A0
Or ASCII characters gen= erally, possibly in
U-labels?=C2=A0

ASCII + UTF8 would interpr= et that as a U-label=C2=A0
=C2=A0
What are "NR-LDH restrictions"?=C2=A0 I d= id not see any such
term defined in rfc5890.=C2=A0 What is defined is "NR-LDH label" = (2.3.2.2).

The reference is for section= 2.3.1.=C2=A0 There NR-LDH stands for Non-Reserved Letters Digits Hyphen wh= ich is intended to exclude A-label and like encodings.=C2=A0 I've spell= ed out NR-LDH and make mention of the intent.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0One suggested approach to apply these sub-
>=C2=A0 =C2=A0 domains restriction is to restrict sub-domain so that lab= els not
>=C2=A0 =C2=A0 start with two letters followed by two hyphen-minus chara= cters.

This makes no sense at all, and should probably be removed.

I've tried to clean up the intent here, which is t= o say that two=C2=A0
=C2=A0

>=C2=A0 =C2=A0 Consistent with the treatment of rfc822Name in [RFC5280],=
>=C2=A0 =C2=A0 SmtpUTF8Name is an envelope <Mailbox> and has no ph= rase (such as a
>=C2=A0 =C2=A0 common name) before it, has no comment (text surrounded i= n
>=C2=A0 =C2=A0 parentheses) after it, and is not surrounded by "<= ;" and ">".

Surely there's no need to drag in any mention of envelopes.=C2=A0


It seems there is IETF history here on envelope vs RFC= 822 email addresses, and rather than revisit this, this document tries keep= s the intent of the rfc822Name as precedence. =C2=A0
=C2=A0
If there is no ABNF c= onstruct elsewhere that gives just the desired
address part, define it here.=C2=A0 Trying to use ABNF by reference
makes this document contorted and unclear.

<= div>I think the intent is more clear adopting existing ABNF.=C2=A0 What do = other folks think?=C2=A0


>=C2=A0 =C2=A0 Due to operational reasons described shortly and name con= straint

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/described/to be described/

Done
=C2=A0

>=C2=A0 =C2=A0 compatibility reasons described in its section,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/its section/<reference to section in quest= ion>/

Done
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SmtpUTF8Name
>=C2=A0 =C2=A0 subjectAltName MUST only be used when the local part of t= he email
>=C2=A0 =C2=A0 address contains UTF-8.

UTF-8 is an encoding, not content:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/containts UTF-8/contains non-ASCII characters= /

Done
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When the local-part is ASCII, rfc822Name<= br> >=C2=A0 =C2=A0 subjectAltName MUST be used instead of SmtpUTF8Name.=C2= =A0 The use of
>=C2=A0 =C2=A0 rfc822Name rather than SmtpUTF8Name is currently more lik= ely to be
>=C2=A0 =C2=A0 supported.

The second sentence would be better as:

=C2=A0 =C2=A0 =C2=A0This is compatible with legacy software that supports o= nly
=C2=A0 =C2=A0 =C2=A0rfc822Name (and not SmtpUTF8Name).

Done
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Also use of Smt= pUTF8Name incurs higher byte
>=C2=A0 =C2=A0 representation overhead due to encoding with otherName an= d the
>=C2=A0 =C2=A0 additional OID needed.=C2=A0 This may be offset if domain= requires non-
>=C2=A0 =C2=A0 ASCII characters as SmtpUTF8Name supports U-label whereas= rfc822Name
>=C2=A0 =C2=A0 supports A-label.

This is not sufficiently compelling to be mentioned.=C2=A0 Please remove.

Done
=C2=A0

> 4.=C2=A0 IDNA2008
>
>=C2=A0 =C2=A0 To facilitate comparison between email addresses, all ema= il address
>=C2=A0 =C2=A0 domain in X.509 certificates MUST conform to IDNA2008 [RF= C5890] (and
>=C2=A0 =C2=A0 excludes any "mappings" mentioned in that docum= ent).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/domain/domains/

Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/excludes/avoid/

Done
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Otherwise non-
>=C2=A0 =C2=A0 conforming email address domains introduces the possibili= ty of
>=C2=A0 =C2=A0 conversion errors between alternate forms.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/Otherwise/Use of/

Done
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 This applies to
>=C2=A0 =C2=A0 SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerA= ltName and
>=C2=A0 =C2=A0 anywhere else that GeneralName is used.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/SmtpUTF8Mailbox/SmtpUTF8Name/

Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/GeneralName is/these are/

Done
=C2=A0

> 5.=C2=A0 Matching of Internationalized Email Addresses in X.509 certif= icates
>
>=C2=A0 =C2=A0 In equivalence comparison with SmtpUTF8Name, there may be= some setup
>=C2=A0 =C2=A0 work to enable the comparison i.e. processing of the Smtp= UTF8Name
>=C2=A0 =C2=A0 content or the email address that is being compared again= st.

This is a lot of words to say very little or nothing at all.=C2=A0 =C2=A0De= lete
or clarify.

Done
=C2=A0
=

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 The
>=C2=A0 =C2=A0 process for setup for comparing with SmtpUTF8Name is spli= t into
>=C2=A0 =C2=A0 domain steps and local- part steps.

The phrase "process for setup for comparing" is exceedingly convo= luted,
please fix.=C2=A0 How about just: "Comparing SmtpUTF8Names consists of= a
domain-part step and a local-part step".

Done
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0The comparison form for local-
>=C2=A0 =C2=A0 part always is UTF-8.=C2=A0 The comparison form for domai= n depends on
>=C2=A0 =C2=A0 context.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/local-part/local-parts/
=
Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/domain/domain-parts/
Done
=C2=A0

>=C2=A0 =C2=A0 Comparison of two SmtpUTF8Name is straightforward with no= setup work
>=C2=A0 =C2=A0 needed.=C2=A0 They are considered equivalent if there is = an exact octet-
>=C2=A0 =C2=A0 for-octet match.

What is expected to be compared are not two "SmtpUTF8Name" object= s,=C2=A0
but such an object with an email address, or such an object with
an rfc822Name constraint.=C2=A0 And, with NR-LDH labels, case insensitive comparison may be required.=C2=A0

Enforcing= insensitivity is done by lower casing the NR-LDH labels mentioned in Secti= on 3.
=C2=A0
Why are we descibing comparisons that
don't happen?

Agreed but as you poi= nt out out next there are a number of scenarios.=C2=A0 As you mention, this= is meant to cover SmtpUTF8Name comparison to EAI header email address, and= comparison of certificate to certificate whose email addresses may be in t= hree different forms.=C2=A0 This intentionally looks for content difference= s (as opposed to format differences) to be sure there is in fact a differen= ce.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Comparison with other email address forms such as

SmtpUTF8Name is not an "email address form", it is a GeneralName = form.
So "other email address forms" is not correct.

Changed to "Comparison with email addresses"
=C2=A0

>=C2=A0 =C2=A0 Internationalized email address or rfc822Name requires ad= ditional
>=C2=A0 =C2=A0 setup steps.=C2=A0 Domain setup is particularly important= for forms that
>=C2=A0 =C2=A0 may contain A- or U-label such as International email add= ress, or
>=C2=A0 =C2=A0 A-label only forms such as rfc822Name.

Clarify or delete.

Simplified.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 This document specifies the
>=C2=A0 =C2=A0 process to transform the domain to U-label.=C2=A0 (To con= vert the domain
>=C2=A0 =C2=A0 to A-label, follow the process specified in section 7.5 a= nd 7.2 in
>=C2=A0 =C2=A0 [RFC5280])

Why the parenthetical comment?=C2=A0

This = serves two purposes- 1) points to a A-label normalization form setup in cas= e that's desired 2) documents the 5280 normalization.=C2=A0 The later i= s the only part that I believe is necessary.=C2=A0 I =C2=A0see your point a= bout confusion, so I've pull the reference into the previous paragraph = where it acts as a more specific reference.
=C2=A0
And we don't specify the proce= ss
of transforming to U-label form.=C2=A0 Rather we require such conversion when one of the addresses being compared employs A-labels.


>=C2=A0 =C2=A0 The first step is to detect A-label by using section 5.1<= br> >=C2=A0 =C2=A0 of [RFC5891].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/A-label/use of A-labels/

Done
=C2=A0

>=C2=A0 =C2=A0 Next if necessary, transform the A-label to U-label
>=C2=A0 =C2=A0 Unicode as specified in section 5.2 of [RFC5891].=C2=A0 F= inally if
>=C2=A0 =C2=A0 necessary convert the Unicode to UTF-8 as specified in se= ction 3 of
>=C2=A0 =C2=A0 [RFC3629].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/the A-label/any A-labels/

Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/U-label/U-labels/

Done
=C2=A0

Nobody will convert to UTF-8 in two separate steps.=C2=A0 In practice
a library will be used that converts from A-label form to UTF-8
encoded Unicode.

>=C2=A0 =C2=A0 For ASCII NR-LDH labels, upper case letters are converted=
>=C2=A0 =C2=A0 to lower case letters.

Fine.

>=C2=A0 =C2=A0 In setup for SmtpUTF8Mailbox, the email
>=C2=A0 =C2=A0 address local-part MUST conform to the requirements of [R= FC6530] and
>=C2=A0 =C2=A0 [RFC6531], including being a string in UTF-8 form.=C2=A0 = In particular,

Given the below, I don't see any need for the above.

An earlier review comment requested citing those document= s to provide context.
=C2=A0

>=C2=A0 =C2=A0 the local-part MUST NOT be transformed in any way, such a= s by doing
>=C2=A0 =C2=A0 case folding or normalization of any kind.=C2=A0 The <= Local-part> part of
>=C2=A0 =C2=A0 an Internationalized email address is already in UTF-8.
>=C2=A0 =C2=A0 To summarize non-normatively, the comparison steps includ= ing setup
>=C2=A0 =C2=A0 are:
>
>=C2=A0 =C2=A0 1.=C2=A0 If the domain contains A-labels, transform them = to U-label.

=C2=A0 =C2=A0 s/U-label/U-labels/

Done<= /div>
=C2=A0

>=C2=A0 =C2=A0 2.=C2=A0 If the domain contains ASCII NR-LDH labels, lowe= rcase them.
>
>=C2=A0 =C2=A0 3.=C2=A0 Ensure local-part is UTF-8.

Since the local-part of email addressees is not accompanied by any
encoding information, it is *presumptively* UTF-8, and there is
nothing to do (or that can be done) in this step.

=
Done
=C2=A0

>=C2=A0 =C2=A0 4.=C2=A0 Compare strings octet-for-octet for equivalence.=

>=C2=A0 =C2=A0 This specification expressly does not define any wildcard= s characters

=C2=A0 =C2=A0 s/wildcards/wildcard/

Don= e
=C2=A0

>=C2=A0 =C2=A0 and SmtpUTF8Name comparison implementations MUST NOT inte= rpret any
>=C2=A0 =C2=A0 character as wildcards.=C2=A0 Instead, to specify multipl= e email addresses
>=C2=A0 =C2=A0 through SmtpUTF8Name, the certificate SHOULD use multiple=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/SHOULD/MUST/

<= div>Done
=C2=A0

>=C2=A0 =C2=A0 subjectAltNames or issuerAltNames to explicitly carry tho= se email
>=C2=A0 =C2=A0 addresses.

=C2=A0 =C2=A0 s/those/any additional/

More to follow.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--94eb2c03d38cf338050552557580-- --94eb2c03d38cfc1f7c0552557501 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAmJB3pCgFDRjjJJnG7/+SW N7J5Qiyh+yGjpd7Hyg6mQTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA2MTkxOTUxMjhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAMkuvQpz1oOWpffFe58NnJvRP57Hy0+VwMvLNsWzK +00loV691DsAIZXvTIv1fiJ+ihz+duMuaLMhwmV4AsE3rGfCp+sS1x9NrQeTfX1qQcc5mLW2gqPJ x7GoWk1mVKUzwQ7NXjSGIi/WZWLe9vo2thL2AM5U8DE3IUYHLScZjKq2BTzuWPtfDt/zQlZDsYnA lo3diJnrHcdaT1z+Xr4JwKBZqUUbMs7IWbPI58duBG1JjU+dFb8qiUw9lT4xt/u5ACGBoWWbtpev MV/kE8FTgSdAmLDt7LWxWWqcdVPVwzCysTyNQ523b+e+0pcFwbdr0tOk5NRatoJwi71xVBqLGA== --94eb2c03d38cfc1f7c0552557501-- From nobody Mon Jun 19 12:51:42 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 BD96F124217 for ; Mon, 19 Jun 2017 12:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 2hbMIbqAv-Cw for ; Mon, 19 Jun 2017 12:51:34 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 6AA47129463 for ; Mon, 19 Jun 2017 12:51:34 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m62so1969562itc.0 for ; Mon, 19 Jun 2017 12:51:34 -0700 (PDT) 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=Fg9wJgTy2AAfSdY8Yz8/VlJSgYddP66OjgNHJbF5lZ0=; b=R/8HeIJRj4qoJglWVNnJHJVPlKGteK3Yorj24T0ry81+lLeXzq01DAKS/3PGgJEZGi pOshAfpsuuXkUwKPpmPHMG4TvocMnxCR5gSSmnJ2r6zXmwcgojMDf1kBquZfxvuOZDqw B5XZvU5fCqnlDaOzOEmsVOrviEG4GvpFY7aypvPmD0x35MBy+i60G7LMLcf5HEYHem+8 s830hBwr/kl9payzBUf6OsYvimMk5hhkE9Fzj/Zv1qL0CFe2jSzHdNhYniwMEaDF47Kw ZjSQXpNs/2GfQA+o8ZzXy01+ObjRZM9+tSEt3iq8RD6Ol4ThWWzz0HiJbnmLCNctoGnI fY4w== 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=Fg9wJgTy2AAfSdY8Yz8/VlJSgYddP66OjgNHJbF5lZ0=; b=L6p89CxAmKvImAff++Kl2MCntcdaACt8vNJRRzbvYNfBEWdGsP8Tvmmih3iYNkEqlb PeYoV23YJsHDixxEaVHPa1N18viEbmuv5RvC4zq1GZdSMYTwTJGK/sEjuVrvhgr5hgrj WG4H6gBQa1Pukk1MhoE7p51bVLobR84jIvH1n2LXAUnDN1IcVfq4ZGbshd/JnpVadyJZ fJumD2RvU2ic0ZVKpHsKGtMNoT7zDE3ucEQHrQVnR+l8+nI7kIw/zUcb6SUiO7LL2p2D WNxT6RutsucW2Uajlv4i4RGZfLGIVUecex0iBm2eaBILWfrJgkRFCOqtXi/iGjVfzVkc OHHg== X-Gm-Message-State: AKS2vOwIEIxsDJMQ1gQe3yQ0fKociHrfS/puRDfGitYV0ucqilsAsWaT pPYEZdSE3LcQnmtP9hTIpjsDVL6FlM7ufwmMgA== X-Received: by 10.36.108.131 with SMTP id w125mr375618itb.91.1497901892450; Mon, 19 Jun 2017 12:51:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.170.142 with HTTP; Mon, 19 Jun 2017 12:51:31 -0700 (PDT) In-Reply-To: <20170614042451.GD23375@mournblade.imrryr.org> References: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> <20170607045725.GI25754@mournblade.imrryr.org> <20170614042451.GD23375@mournblade.imrryr.org> From: Wei Chuang Date: Mon, 19 Jun 2017 12:51:31 -0700 Message-ID: To: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1147e2a449996705525576aa" Archived-At: Subject: Re: [lamps] draft-ietf-lamps-eai-addresses-10 full review Part 2 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 19:51:38 -0000 --001a1147e2a449996705525576aa Content-Type: multipart/alternative; boundary="001a1147e2a435f8940552557602" --001a1147e2a435f8940552557602 Content-Type: text/plain; charset="UTF-8" Thanks Viktor for the detailed review. -Wei On Tue, Jun 13, 2017 at 9:24 PM, Viktor Dukhovni wrote: > > > 6. Name constraints in path validation > > > > This section updates [RFC5280] name constraints defined in section > > 4.2.1.10 to work with SmtpUTF8Name subjectAltName. > Better something along the lines of: > > This section updates section 4.2.1.10 of [RFC5280] to extend > rfc822Name name constraints to SmtpUTF8Name subjectAltNames. > Done > > > > The following > > specifies that a SmtpUTF8Name aware CA use a compatible name > > constraint representation. > > What's a "compatible name constraint representation"? Either > clarify or delete... > Deleted > > > Similarly a SmtpUTF8Name aware path > > validators MUST be able to apply name constraint comparison to the > > subject distinguished name and both forms of subject alternative name > > rfc822Name and SmtpUTF8Name. > > It is I think long past time to end support for extracting DNS-ID > names and email email addresses from the certificate subject DN. > We should consider updating 5280 to drop support for matching > "emailAddress" in the subject DN when no rfc822name subject > alternative names are present. If so, perhaps there should be no > mention of enforcing email name constraints against the subject DN. > I do agree that dropping subject DN is a good idea. Other opinions? (I left in for now) > > Also, it is not clear what the "MUST" here means. It seems to me > that this sentence is design rationale, not a protocol requirement. > Its defining a "SmtpUTF8Name aware path validator". > > > The SmtpUTF8Name aware email address name constraint form is > > specified to be rfc822Name motivated by compatibility considerations > > with legacy systems that already understand that form. > > Better: > > Both rfc822Name and SmtpUTF8Name subject alternative names > represent the same underlying email address namespace. Since > legacy CAs constrained to issue certificates for a specific > set of domains would lack corresponding UTF-8 constraints, > this specification modifies and extends rfc822Name name > constraints to cover SmtpUTF8Name subject alternative names. > This ensures that the introduction of SmtpUTF8Name does not > violate existing name constraints. > Done > > > This > > specification modifies [RFC5280] name constraint to only require with > > MAY that it represents all addresses at a host or all mailboxes in a > > domain, and require with MAY NOT that it represent a particular > > mailbox. > > Better: > > Since it is not valid to include non-ASCII UTF-8 characters > in the local-part of rfc822Name name constraints, and since > name constraints that include a local-part are rarely, if at > all, used in practice, this specification modifies [RFC5280] > name constraints to only admit the forms represent all addresses > at a host or all mailboxes in a domain, and deprecates rfc822Name > name constraints that represent a particular mailbox. That is, > rfc822Name constraints with a local-part MUST NOT be used. > Done, thought the MUST NOT is changed to SHOULD NOT to allow a transition. I am worried that there may have been some use of name constraint w/local part email address, and this would cause unforeseen breakage. > > > For context, [RFC5280] Section 4.2.1.10 specifies with MAY > > that name constraint represent a particular mailbox, all addresses at > > a host, or all mailboxes in a domain by specifying the complete email > > address, a host name, or a domain. The change is due to rfc822Name > > name constraints inability to represent a specific mailbox with a > > UTF-8 email local part email address. CA certificate issuers should > > be aware of this lessened support. > > Delete. > Done > > > Constraint comparison with SmtpUTF8Name subjectAltName starts with > > the setup steps defined by Section 5. The setup applies to the > > inputs of the comparison which is one of a subject distinguished name > > or a rfc822Name or SmtpUTF8Name subjectAltName, and one of a > > rfc822Name name constraint. > > Delete, and instead describe the actual process. > Expanded. > > > Non-normatively the setup will convert > > any domain A-label to U-label in the rfc822Name name constraint, and > > to lower case any domain NR-LDH label in both the name constraint and > > the subject. > > Instead of "non-normatively", specify that comparison MUST be equivalent > to: > > 0. CA certificates which include rfc822Name name constraints > with a local-part are now invalid for issuing end-entity > email certificates. Equivalently, such CA certificates > now exclude all rfc822Name and SmtpUTF8Name subject > alternative names in the end-entity certificate. > Noted above. > > 1. Strip the local-part and "@" separator from each rfc822Name and > SmtpUTF8Name, leaving just the domain-part. > > 2. Decoding any A-labels in the rfc822Name name constraint to > U-labels. > > 3. Converting any NR-LDH labels in the rfc822Name name constraint to > lower case. > > 4. Decoding any A-labels in the domain-part of each rfc822Name > or SmtpUTF8Name subject alternative name to U-labels. > > 5. Converting any NR-LDH labels in the domain-part of each > rfc822Name or SmtpUTF8Name subject alternative name to > lower case. > > 6. If the resulting name constraint domain starts with a "." > character, then for the name constraint to match, a suffix > of the resulting subject alternative name domain MUST match > the name constraint (including the leading ".") octet for octet. > > 7. If the resulting name constraint domain does not start with a "." > character, then for the name constraint to match, the entire > resulting subject alternative name domain MUST match the > name constraint octet for octet. > > > After setup, this follows the comparison steps defined > > in 4.2.1.10 of [RFC5280] with some modifications as follows. The > > comparison process starts by determining the name constraint > > representation i.e. email host name or domain part, then comparing > > the name constraint against the corresponding part in the email > > address using a byte for byte comparison. This document suggests > > that name constraint comparison with subject distinguished name or > > rfc822Name subjectAltName also follow these setup and comparisons > > steps as well. > > Delete. > > There should be some discussion of what CAs are expected to do when > issuing constrained intermediate subsidiary CAs (accept only IDNA2008 > conformant names with no mappings, converting to A-labels in > rfc822Name subject alternative names and name constraints). > Done > > > The name constraint requirement with SmtpUTF8Name subject alternative > > name is illustrated in the non-normative diagram Figure 1. The first > > example (1) illustrates a permitted rfc822Name ASCII only hostname > > name constraint, and the corresponding valid rfc822Name > > subjectAltName and SmtpUTF8Name subjectAltName email addresses. The > > second example (2) illustrates a permitted rfc822Name hostname name > > constraint with A-label, and the corresponding valid rfc822Name > > subjectAltName and SmtpUTF8Name subjectAltName email addresses. > > > > I would here re-iterate the requirement to use an A-label domain-part > encoding in an rfc822Name subject alternative name when the local-part > is all-ASCII. > Done. > > > +-------------------------------------------------------------------+ > > | Root CA Cert | > > +-------------------------------------------------------------------+ > > v > > +-------------------------------------------------------------------+ > > | Intermediate CA Cert | > > | Permitted | > > | rfc822Name: elementary.school.example.com (1) | > > | rfc822Name: xn--pss25c.example.com (2) | > > +-------------------------------------------------------------------+ > > v > > +-------------------------------------------------------------------+ > > | Entity Cert (w/explicitly permitted subjects) | > > | SubjectAltName Extension | > > | rfc822Name: student@elemenary.school.example.com (1) | > > | SmtpUTF8Name: u+5B66u+751F@elementary.school.example.com (1) | > > | | > > | rfc822Name: student@xn--pss25c.example.com (2) | > > | SmtpUTF8Name: u+533Bu+751F@u+5927u+5B66.example.com (2) | > > +-------------------------------------------------------------------+ > > > > Name constraints with SmtpUTF8Name and rfc822Name > > > > Figure 1 > > > 7. Security Considerations > > > > Use for SmtpUTF8Name for certificate subjectAltName (and > > issuerAltName) will incur many of the same security considerations of > > Section 8 in [RFC5280] but is further complicated by permitting non- > > ASCII characters in the email address local-part. > > s/Use for/Use of/ > Done > s/of Section 8/as in Section 8/ > Done > s/but is further complicated/, but introduces a new issue/ > Done > > > This complication, > > as mentioned in Section 4.4 of [RFC5890] and in Section 4 of > > [RFC6532], is that use of Unicode introduces the risk of visually > > similar and identical characters which can be exploited to deceive > > the recipient. > > s/This complication/The issue/ > Done > > -- > Viktor. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a1147e2a435f8940552557602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Viktor for the detailed review.

= -Wei

On Tue, J= un 13, 2017 at 9:24 PM, Viktor Dukhovni <ietf-dane@dukhovni.org&g= t; wrote:

> 6.=C2=A0 Name constraints in path validation
>
>=C2=A0 =C2=A0 This section updates [RFC5280] name constraints defined i= n section
>=C2=A0 =C2=A0 4.2.1.10 to work with SmtpUTF8Name subjectAltName.

Better something along the lines of:

=C2=A0 =C2=A0 =C2=A0This section updates section 4.2.1.10 of [RFC5280] to e= xtend
=C2=A0 =C2=A0 =C2=A0rfc822Name name constraints to SmtpUTF8Name subjectAltN= ames.

Done
=C2=A0


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The following
>=C2=A0 =C2=A0 specifies that a SmtpUTF8Name aware CA use a compatible n= ame
>=C2=A0 =C2=A0 constraint representation.

What's a "compatible name constraint representation"?=C2=A0 E= ither
clarify or delete...

Deleted
= =C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Similarly a SmtpUTF8Name aware pa= th
>=C2=A0 =C2=A0 validators MUST be able to apply name constraint comparis= on to the
>=C2=A0 =C2=A0 subject distinguished name and both forms of subject alte= rnative name
>=C2=A0 =C2=A0 rfc822Name and SmtpUTF8Name.

It is I think long past time to end support for extracting DNS-ID
names and email email addresses from the certificate subject DN.
We should consider updating 5280 to drop support for matching
"emailAddress" in the subject DN when no rfc822name subject
alternative names are present.=C2=A0 If so, perhaps there should be no
mention of enforcing email name constraints against the subject DN.

I do agree that dropping subject DN is a good = idea.=C2=A0 Other opinions? =C2=A0(I left in for now)
=C2=A0

Also, it is not clear what the "MUST" here means.=C2=A0 It seems = to me
that this sentence is design rationale, not a protocol requirement.

Its defining a "SmtpUTF8Name aware path v= alidator".
=C2=A0

>=C2=A0 =C2=A0 The SmtpUTF8Name aware email address name constraint form= is
>=C2=A0 =C2=A0 specified to be rfc822Name motivated by compatibility con= siderations
>=C2=A0 =C2=A0 with legacy systems that already understand that form.
Better:

=C2=A0 =C2=A0 =C2=A0Both rfc822Name and SmtpUTF8Name subject alternative na= mes
=C2=A0 =C2=A0 =C2=A0represent the same underlying email address namespace.= =C2=A0 Since
=C2=A0 =C2=A0 =C2=A0legacy CAs constrained to issue certificates for a spec= ific
=C2=A0 =C2=A0 =C2=A0set of domains would lack corresponding UTF-8 constrain= ts,
=C2=A0 =C2=A0 =C2=A0this specification modifies and extends rfc822Name name=
=C2=A0 =C2=A0 =C2=A0constraints to cover SmtpUTF8Name subject alternative n= ames.
=C2=A0 =C2=A0 =C2=A0This ensures that the introduction of SmtpUTF8Name does= not
=C2=A0 =C2=A0 =C2=A0violate existing name constraints.

Done
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This
>=C2=A0 =C2=A0 specification modifies [RFC5280] name constraint to only = require with
>=C2=A0 =C2=A0 MAY that it represents all addresses at a host or all mai= lboxes in a
>=C2=A0 =C2=A0 domain, and require with MAY NOT that it represent a part= icular
>=C2=A0 =C2=A0 mailbox.

Better:

=C2=A0 =C2=A0 =C2=A0Since it is not valid to include non-ASCII UTF-8 charac= ters
=C2=A0 =C2=A0 =C2=A0in the local-part of rfc822Name name constraints, and s= ince
=C2=A0 =C2=A0 =C2=A0name constraints that include a local-part are rarely, = if at
=C2=A0 =C2=A0 =C2=A0all, used in practice, this specification modifies [RFC= 5280]
=C2=A0 =C2=A0 =C2=A0name constraints to only admit the forms represent all = addresses
=C2=A0 =C2=A0 =C2=A0at a host or all mailboxes in a domain, and deprecates = rfc822Name
=C2=A0 =C2=A0 =C2=A0name constraints that represent a particular mailbox.= =C2=A0 That is,
=C2=A0 =C2=A0 =C2=A0rfc822Name constraints with a local-part MUST NOT be us= ed.

Done, thought the MUST NOT is chang= ed to SHOULD NOT to allow a transition.=C2=A0 I am worried that there may h= ave been some use of name constraint w/local part email address, and this w= ould cause unforeseen breakage.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 For context, [RFC5280]= Section 4.2.1.10 specifies with MAY
>=C2=A0 =C2=A0 that name constraint represent a particular mailbox, all = addresses at
>=C2=A0 =C2=A0 a host, or all mailboxes in a domain by specifying the co= mplete email
>=C2=A0 =C2=A0 address, a host name, or a domain.=C2=A0 The change is du= e to rfc822Name
>=C2=A0 =C2=A0 name constraints inability to represent a specific mailbo= x with a
>=C2=A0 =C2=A0 UTF-8 email local part email address.=C2=A0 CA certificat= e issuers should
>=C2=A0 =C2=A0 be aware of this lessened support.

Delete.

Done
=C2=A0

>=C2=A0 =C2=A0 Constraint comparison with SmtpUTF8Name subjectAltName st= arts with
>=C2=A0 =C2=A0 the setup steps defined by Section 5.=C2=A0 The setup app= lies to the
>=C2=A0 =C2=A0 inputs of the comparison which is one of a subject distin= guished name
>=C2=A0 =C2=A0 or a rfc822Name or SmtpUTF8Name subjectAltName, and one o= f a
>=C2=A0 =C2=A0 rfc822Name name constraint.

Delete, and instead describe the actual process.

<= /div>
Expanded.



>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Non-normatively the setup w= ill convert
>=C2=A0 =C2=A0 any domain A-label to U-label in the rfc822Name name cons= traint, and
>=C2=A0 =C2=A0 to lower case any domain NR-LDH label in both the name co= nstraint and
>=C2=A0 =C2=A0 the subject.

Instead of "non-normatively", specify that comparison MUST be equ= ivalent
to:

=C2=A0 =C2=A0 0.=C2=A0 CA certificates which include rfc822Name name constr= aints
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with a local-part are now invalid for issuing e= nd-entity
=C2=A0 =C2=A0 =C2=A0 =C2=A0 email certificates.=C2=A0 Equivalently, such CA= certificates
=C2=A0 =C2=A0 =C2=A0 =C2=A0 now exclude all rfc822Name and SmtpUTF8Name sub= ject
=C2=A0 =C2=A0 =C2=A0 =C2=A0 alternative names in the end-entity certificate= .

Noted above.
=C2=A0

=C2=A0 =C2=A0 1.=C2=A0 Strip the local-part and "@" separator fro= m each rfc822Name and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SmtpUTF8Name, leaving just the domain-part.

=C2=A0 =C2=A0 2.=C2=A0 Decoding any A-labels in the rfc822Name name constra= int to U-labels.

=C2=A0 =C2=A0 3.=C2=A0 Converting any NR-LDH labels in the rfc822Name name = constraint to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lower case.

=C2=A0 =C2=A0 4.=C2=A0 Decoding any A-labels in the domain-part of each rfc= 822Name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or SmtpUTF8Name subject alternative name to U-l= abels.

=C2=A0 =C2=A0 5.=C2=A0 Converting any NR-LDH labels in the domain-part of e= ach
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rfc822Name or SmtpUTF8Name subject alternative = name to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lower case.

=C2=A0 =C2=A0 6.=C2=A0 If the resulting name constraint domain starts with = a "."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 character, then for the name constraint to matc= h, a suffix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the resulting subject alternative name domai= n MUST match
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the name constraint (including the leading &quo= t;.") octet for octet.

=C2=A0 =C2=A0 7.=C2=A0 If the resulting name constraint domain does not sta= rt with a "."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 character, then for the name constraint to matc= h, the entire
=C2=A0 =C2=A0 =C2=A0 =C2=A0 resulting subject alternative name domain MUST = match the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 name constraint octet for octet.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 After se= tup, this follows the comparison steps defined
>=C2=A0 =C2=A0 in 4.2.1.10 of [RFC5280] with some modifications as follo= ws.=C2=A0 The
>=C2=A0 =C2=A0 comparison process starts by determining the name constra= int
>=C2=A0 =C2=A0 representation i.e. email host name or domain part, then = comparing
>=C2=A0 =C2=A0 the name constraint against the corresponding part in the= email
>=C2=A0 =C2=A0 address using a byte for byte comparison.=C2=A0 This docu= ment suggests
>=C2=A0 =C2=A0 that name constraint comparison with subject distinguishe= d name or
>=C2=A0 =C2=A0 rfc822Name subjectAltName also follow these setup and com= parisons
>=C2=A0 =C2=A0 steps as well.

Delete.

There should be some discussion of what CAs are expected to do when
issuing constrained intermediate subsidiary CAs (accept only IDNA2008
conformant names with no mappings, converting to A-labels in
rfc822Name subject alternative names and name constraints).

Done
=C2=A0

>=C2=A0 =C2=A0 The name constraint requirement with SmtpUTF8Name subject= alternative
>=C2=A0 =C2=A0 name is illustrated in the non-normative diagram Figure 1= .=C2=A0 The first
>=C2=A0 =C2=A0 example (1) illustrates a permitted rfc822Name ASCII only= hostname
>=C2=A0 =C2=A0 name constraint, and the corresponding valid rfc822Name >=C2=A0 =C2=A0 subjectAltName and SmtpUTF8Name subjectAltName email addr= esses.=C2=A0 The
>=C2=A0 =C2=A0 second example (2) illustrates a permitted rfc822Name hos= tname name
>=C2=A0 =C2=A0 constraint with A-label, and the corresponding valid rfc8= 22Name
>=C2=A0 =C2=A0 subjectAltName and SmtpUTF8Name subjectAltName email addr= esses.
>

I would here re-iterate the requirement to use an A-label domain-part
encoding in an rfc822Name subject alternative name when the local-part
is all-ASCII.

Done.
=C2=A0

>=C2=A0 =C2=A0 +---------------------------------------------------= ----------------+
>=C2=A0 =C2=A0 |=C2=A0 Root CA Cert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
>=C2=A0 =C2=A0 +---------------------------------------------------= ----------------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
>=C2=A0 =C2=A0 +---------------------------------------------------= ----------------+
>=C2=A0 =C2=A0 |=C2=A0 Intermediate CA Cert=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 Permitted=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 rfc822Name: eleme= ntary.school.example.com (1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 rfc822Name: xn--pss25c.e= xample.com (2)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 +---------------------------------------------------= ----------------+
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
>=C2=A0 =C2=A0 +---------------------------------------------------= ----------------+
>=C2=A0 =C2=A0 |=C2=A0 Entity Cert (w/explicitly permitted subjects)=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 SubjectAltName Extension=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 rfc822Name: student@elemenary.school.example.com<= /a> (1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 SmtpUTF8Name: u+5B66u+751F@elementary.s= chool.example.com (1) |
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 rfc822Name: student@xn--pss25c.example.com (2)=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 SmtpUTF8Name: u+533Bu+751F@u+5927u+= 5B= 66.example.com (2)=C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 +---------------------------------------------------= ----------------+
>
>=C2=A0 =C2=A0 Name constraints with SmtpUTF8Name and rfc822Name
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 1

> 7.=C2=A0 Security Considerations
>
>=C2=A0 =C2=A0 Use for SmtpUTF8Name for certificate subjectAltName (and<= br> >=C2=A0 =C2=A0 issuerAltName) will incur many of the same security consi= derations of
>=C2=A0 =C2=A0 Section 8 in [RFC5280] but is further complicated by perm= itting non-
>=C2=A0 =C2=A0 ASCII characters in the email address local-part.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/Use for/Use of/

Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/of Section 8/as in Section 8/

Done
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/but is further complicated/, but introduces a= new issue/

Done
=C2=A0
=

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This complication,
>=C2=A0 =C2=A0 as mentioned in Section 4.4 of [RFC5890] and in Section 4= of
>=C2=A0 =C2=A0 [RFC6532], is that use of Unicode introduces the risk of = visually
>=C2=A0 =C2=A0 similar and identical characters which can be exploited t= o deceive
>=C2=A0 =C2=A0 the recipient.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s/This complication/The issue/
=

Done
=C2=A0

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--001a1147e2a435f8940552557602-- --001a1147e2a449996705525576aa 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAynVRUCMdHxIZqzV9ry3/7 /vU/RShD/dJ5cSh+AQWWMjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA2MTkxOTUxMzNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAjm/lpA0UGqh345j3GQ96h/55TyOk38lPWq7rzAZr VAo4kG8vdIfrZdAOTv7oYmSnw5qY65KewqcKO90AJfVgWcImd6cLIeayKmrntOATqYUX8GFH7rGo DV8bPfFf9f4ZNngcMNK6Qdg05QzxsBTLd76HlA0yJfBCxjSHt1CvzY39wfjEGqfpCserM1no3Pfh B/w73XKISJvlQUZ32b5rEYqWfVwcKSqXFwSS7jQxOxPiJKymWBfX9Yg/O9mEq5u1STzZYpGBLXfM ZgwFlM6UShu3NpmWQnaP69KLa67r9CfBFUh6Qx4R/OQtH2QI5JIsaaYcmn3rVbbHxoVPdka2OA== --001a1147e2a449996705525576aa-- From nobody Mon Jun 19 12:51:56 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 6BE4A124217; Mon, 19 Jun 2017 12:51:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149790190439.10769.4874371254066357165@ietfa.amsl.com> Date: Mon, 19 Jun 2017 12:51:44 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-eai-addresses-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jun 2017 19:51:44 -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-11.txt Pages : 11 Date : 2017-06-19 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-11 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-11 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 Jun 22 06:39: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 464EA1292AE for ; Thu, 22 Jun 2017 06:39:38 -0700 (PDT) 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 KA2DaQmJ032Y for ; Thu, 22 Jun 2017 06:39:31 -0700 (PDT) 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 87088124C27 for ; Thu, 22 Jun 2017 06:39:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DA97E3004D0 for ; Thu, 22 Jun 2017 09:39:28 -0400 (EDT) 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 S23Zw4lKrvf4 for ; Thu, 22 Jun 2017 09:39:27 -0400 (EDT) Received: from [192.168.6.250] (ip-64-134-240-18.public.wayport.net [64.134.240.18]) by mail.smeinc.net (Postfix) with ESMTPSA id E8C5A300266; Thu, 22 Jun 2017 09:39:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <149790190464.10769.10138265629051334555.idtracker@ietfa.amsl.com> Date: Thu, 22 Jun 2017 09:39:23 -0400 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: <7D6AC11A-1F96-4072-B163-E7DFC4EA1A94@vigilsec.com> References: <149790190464.10769.10138265629051334555.idtracker@ietfa.amsl.com> To: Alexey Melnikov , Wei Chuang X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-eai-addresses-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 13:39:38 -0000 I have a few minor comments on this document. Section 5 says: ... (section 7.5 and 7.2 in [RFC5280]) ... These sections are updated by draft-ietf-lamps-rfc5280-i18n-update-01. It would help the reader to point to this document as well. Maybe: ... (sections 7.2 and 7.5 in [RFC5280] as updated by = [ID-lamps-rfc5280-i18n-update]) ... Section 6 says: =E2=80=A6 this specification modifies and extends rfc822Name name SmtpUTF8Name does not violate existing name constraints. I cannot figure out what this sentence is trying to say. Please reword. Section 6 has text to forbid constraints on the local-part of email = addresses. This update to RFC 5280 is already included in = draft-ietf-lamps-rfc5280-i18n-update-01. I do not think that it needs to be in both documents. I suggest that = this document point to the change. In Section 8: s/in Section Section 3/In Section 3/ s/Section Appendix A./Appendix A./ In Appendix A, please remove "Figure 2=E2=80=9D from the end of the = ASN.1 module. I hope these few comments can be addressed in the next few days. They = are all simple. Russ > On Jun 19, 2017, at 3:51 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-lamps-eai-addresses-11.txt > has been successfully submitted by Weihaw Chuang and posted to the > IETF repository. >=20 > Name: draft-ietf-lamps-eai-addresses > Revision: 11 > Title: Internationalized Email Addresses in X.509 = certificates > Document date: 2017-06-18 > Group: lamps > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-eai-addresses-11.txt= > Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-11 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-11 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-11 >=20 > Abstract: > This document defines a new name form for inclusion in the otherName > field of an X.509 Subject Alternative Name and Issuer Alternative > Name extension that allows a certificate subject to be associated > with an Internationalized Email Address. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Thu Jun 22 12:52:25 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 5F0C5129B5C for ; Thu, 22 Jun 2017 12:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 2Uxd06XDD02l for ; Thu, 22 Jun 2017 12:52:20 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C745128799 for ; Thu, 22 Jun 2017 12:52:20 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id p187so14920436oif.3 for ; Thu, 22 Jun 2017 12:52:20 -0700 (PDT) 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=ArKvxXWOCFZ+q4pX+RhqPUlCjMzzA+8ELAkZzESjuUY=; b=YZ87LydZ2N5bZ0G8AZo5jRpXChf1naAIshLviKRC9LgCwUrPjbSFd/ijOYTaIL9J2t TAT4j1tqMRQYxf/ZPmCt20kAEidqFGlKRNq+Kc8GTviLDr7V2rmZcOD0I5/M0yWBAcH5 x0PWSIaEw/ISQPXd6d3RcsLzwKCPeOEuQrQqcTnxNyU8l1W+mPgtsK2ZrXkmAOUjc9Dr AN8GeS02MbBlFZwHmpwfOJStK14lfbhLrJUZ0PbO5mxCKxuwbz3jeUr7q1YCuFkOESuw zPOAPr2mqWW7KEV6KubLdpF6zjFvAaa3zsvUjn31l3qEplEHE28yjymwxfXWpKbs7k7x 6STA== 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=ArKvxXWOCFZ+q4pX+RhqPUlCjMzzA+8ELAkZzESjuUY=; b=c9lEsxRgQL6GlGK5PHWdngMNbscDCkm/pLRK+f760cZzVnVhTAsPPnnC7IVoRfgQPx YPzd4+7ZdwET5hXmjgz3pgWmLomWd5DfzttC96MiV3VTJWVWuW/0FgZ311szthx+ky6b +UmqdSEIYphuzHyAaUks5R/xX3B9+HuCB7AelpKRGWet90F95OU8V18+rpg7garP9FGw hPP+kHAHGGxRHZUBqER70EFAxKA0p/D54RQxe7pZ4bSbEwFNY8C1+GLQ9/Zd97A8eyVn ZUZja1Fj11J7VgyeSd01CC6uavGfgHcLc6MA0xGAT0oKLmhD2HSqAi+IwJKFOWyKUuq8 20dA== X-Gm-Message-State: AKS2vOwKdVc00lrwLB4cSpGukVdGfVulhmQ1p1zoM8BesgC0fdbm4y+f 87iuM8zXwaLP5aG/mXmKIgs0IExQDw== X-Received: by 10.202.236.141 with SMTP id k135mr2281297oih.20.1498161139633; Thu, 22 Jun 2017 12:52:19 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.206 with HTTP; Thu, 22 Jun 2017 12:52:18 -0700 (PDT) In-Reply-To: References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Thu, 22 Jun 2017 15:52:18 -0400 X-Google-Sender-Auth: Nhz09CRJIlPi_Vcv_ILRB6KdCEI Message-ID: To: "Salz, Rich" Cc: Jacob Hoffman-Andrews , SPASM , Rob Stradling Content-Type: multipart/alternative; boundary="001a1134fc248b5573055291d28e" Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jun 2017 19:52:23 -0000 --001a1134fc248b5573055291d28e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In response to comments by a non list subscriber: s/follow the CNAME record/follow the CNAME record chain s/ten or fewer/8 or fewer/ The first is just for clarity and the second is because it turns out that unbound has a hard limit of 8 CNAME records to follow in a chain which provides a justification for a number that was previously arbitrary. If there is a revision of RFC1035 to specify a limit it will certainly follow unbound unless there is another library in common use with a different limit. Corrected Text -------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record chain specified at the label X. o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D CAA(A(X)), otherwise o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise o R(X) is empty. Thus, when a search at node X returns a CNAME record, the CA will follow the CNAME record chain to its target. If the target label contains a CAA record, it is returned. =E2=80=8BO=E2=80=8B therwise, the CA continues the search at the parent of node X. Note that the search does not include the parent of a target of a CNAME record (except when the CNAME points back to its own path). To prevent resource exhaustion attacks, CAs should limit the length of CNAME chains that are accepted. However CAs MUST process CNAME chains that contain 8 or fewer CNAME records. On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker wrote: > The RFC Editor has deleted all three of the existing errata. I would like > for the next errata to be the very last. > > > > Could people read, review and state if this works for them? > =E2=80=8B This text is the same as the one I posted to CABForum earlier w= ith the > one exception being that I capitalized Otherwise in the place it needed i= t.=E2=80=8B > > > > > Original Text > > ------------- > > Let CAA(X) be the record set returned in response to performing a CAA > > record query on the label X, P(X) be the DNS label immediately above > > X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME > > alias record specified at the label X. > > > > o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise > > > > o If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D > > R(A(X)), otherwise > > > > o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise > > > > o R(X) is empty. > > > > > > Corrected Text > > -------------- > > Let CAA(X) be the record set returned in response to performing a CAA > > record query on the label X, P(X) be the DNS label immediately above > > X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME > > alias record chain specified at the label X. > > > > o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise > > > > o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D > > CAA(A(X)), otherwise > > > > o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise > > > > o R(X) is empty. > > > > Thus, when a search at node X returns a CNAME record, the CA will > > follow the CNAME record to its target. If the target label contains a > > CAA record, it is returned. > =E2=80=8BO=E2=80=8B > therwise, the CA continues the search at > > the parent of node X. > > > > Note that the search does not include the parent of a target of a > > CNAME record (except when the CNAME points back to its own path). > > > > To prevent resource exhaustion attacks, CAs should limit the length of > > CNAME chains that are accepted. However CAs MUST process CNAME > > chains that contain ten or fewer CNAME records. > > > > Processing for DNAME is exactly the same as for CNAME. Note that since > > DNAME records are implemented by creating the corresponding CNAME > > records on the fly, it is only necessary for DNAME records to appear > > on the wire for purposes of DNSSEC. > --001a1134fc248b5573055291d28e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

In response to com= ments by a non list subscriber:


s/= follow the CNAME record/follow the CNAME record chain

s/ten or fewe= r/8 or fewer/


The first is just for clarit= y and the second is because it turns out that unbound has a hard limit of 8= CNAME records to follow in a chain which provides a justification for a nu= mber that was previously arbitrary.


If the= re is a revision of RFC1035 to specify a limit it will certainly follow unb= ound unless there is another library in common use with a different limit.<= /p>



Corrected Text

--------------

=C2=A0=C2=A0 Let=C2=A0CAA(X) be the record set returned in response to perfo= rming a=C2=A0CAA

=C2=A0=C2=A0 record query on the label X, P(X) be the DNS label immediat= ely above

=C2=A0=C2=A0 X in the DNS hier= archy, and A(X) be the target of a CNAME or DNAME

=C2=A0=C2=A0 alias r= ecord chain specified at the label X.

= =C2=A0

=C2=A0=C2=A0 o=C2=A0 If=C2=A0CAA(X) is not empty, R(X) =3D=C2=A0C= AA=C2=A0(X), otherwise

=C2=A0<= /u>

=C2=A0=C2=A0 o=C2=A0 If A(X) is not null, and=C2=A0CAA(A(X)) is not empty, then R(X) =3D

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0CAA(A(X)), otherwise

=C2=A0=

=C2=A0=C2=A0 o=C2=A0 If X is not a top-level domain, the= n R(X) =3D R(P(X)), otherwise

=C2=A0<= /u>

=C2=A0=C2=A0 o=C2=A0 R(X) is empty.

=C2=A0

=C2=A0 Thus, when a search at nod= e X returns a CNAME record, the CA will

=C2=A0 = follow the CNAME record chain to its target. If the target label=C2=A0

<= p class=3D"gmail-m_5468644719731642358gmail-m_-6888537177182227715MsoPlainT= ext" style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sa= ns-serif">=C2=A0 contains a=C2=A0CAA=C2=A0record, it is= returned.


= =E2=80=8BO=E2=80=8B
therwise, the CA continues the search at

= =C2=A0 the parent of node X.

=C2=A0

=C2=A0 Note that the search does not include the pa= rent of a target of a

=C2=A0 CNAME record (except when the CNAME point= s back to its own path).

=C2=A0

=C2=A0To prevent resource exhaustion attacks, CAs shoul= d limit the length of

=C2=A0=C2=A0CNAME chains = that are accepted. However CAs MUST process CNAME

=C2=A0=C2=A0chains that contain 8 or fewer CNAME records.


On Wed, Jun 14, = 2017 at 7:11 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

The RFC Editor has deleted all three of the existi= ng errata. I would like for the next errata to be the very last.
=

=C2=A0

Could people read, re= view and state if this works for them?

=E2=80=8B This text is the same as the= one I posted to CABForum earlier with the one exception being that I capit= alized Otherwise in the place it needed it.=E2=80=8B

=


=C2=A0

Original Text<= /u>

-------------

=C2= =A0=C2=A0 Let CAA(X) be the record set returned in response to performing a= CAA

=C2=A0=C2=A0 record query on the label X, P(X) b= e the DNS label immediately above

=C2=A0=C2=A0 X in t= he DNS hierarchy, and A(X) be the target of a CNAME or DNAME<= /p>

=C2=A0=C2=A0 alias record specified at the label X.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If CAA(X) is not e= mpty, R(X) =3D CAA (X), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If A(X) is not null, and R(A(X)) is not empt= y, then R(X) =3D

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 R(A(X= )), otherwise

=C2=A0

=C2=A0=C2= =A0 o=C2=A0 If X is not a top-level domain, then R(X) =3D R(P(X)), otherwis= e

=C2=A0

=C2=A0=C2=A0 o=C2=A0 R= (X) is empty.

=C2=A0

=C2=A0

Corrected Text

--------------

=C2=A0=C2=A0 Let C= AA(X) be the record set returned in response to performing a CAA<= /u>

=C2=A0=C2=A0 record query on the label X, P(X) be the DNS label= immediately above

=C2=A0=C2=A0 X in the DNS h= ierarchy, and A(X) be the target of a CNAME or DNAME

=C2=A0=C2=A0 alias record chain specified at the label X.<= u>

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If = CAA(X) is not empty, R(X) =3D CAA (X), otherwise

= =C2=A0

=C2=A0=C2=A0 o=C2=A0 If A(X) is not null, and CAA= (A(X)) is not empty, then R(X) =3D

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 CAA(A(X)), otherwise

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If X is not a top-level domain, then R(X) = =3D R(P(X)), otherwise

=C2=A0

= =C2=A0=C2=A0 o=C2=A0 R(X) is empty.

=C2=A0<= /u>

=C2=A0 Thus, when a search at node X returns a CNAME record, th= e CA will

=C2=A0 follow the CNAME record to its targe= t. If the target label contains a

=C2=A0 CAA record, = it is returned.

=E2=80=8BO=E2=80=8B
therwise, t= he CA continues the search at

=C2=A0 the parent of= node X.

=C2=A0

=C2=A0 N= ote that the search does not include the parent of a target of a<= /u>

=C2=A0 CNAME record (except when the CNAME poi= nts back to its own path).

=C2=A0

=C2=A0To prevent resource exhaustion attacks, CAs should limit th= e length of

=C2=A0=C2=A0CNAME chains that are accepte= d. However CAs MUST process CNAME

=C2=A0=C2=A0chains = that contain ten or fewer CNAME records.

=

=C2=A0

=C2=A0 Processing for DNAME is exactly th= e same as for CNAME. Note that since

=C2=A0 DNAME rec= ords are implemented by creating the corresponding CNAME

<= p class=3D"m_5468644719731642358gmail-m_-6888537177182227715MsoPlainText" s= tyle=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-ser= if">=C2=A0 records on the fly, it is only necessary for DNAME records to ap= pear

=C2=A0 on the wire for purposes of DNSSEC.


--001a1134fc248b5573055291d28e-- From nobody Fri Jun 23 10:56: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 2DBBC1293F4 for ; Fri, 23 Jun 2017 10:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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=-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=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 8-uw38Hf2_50 for ; Fri, 23 Jun 2017 10:56:32 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 2F7421270A3 for ; Fri, 23 Jun 2017 10:56:32 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id j53so40973029uaa.2 for ; Fri, 23 Jun 2017 10:56:32 -0700 (PDT) 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 :cc; bh=onJnQ9sf1KkUP+vU7AzX97/F4q8yd1pXcTcL9EjsHtM=; b=GWbXU2fSd5B++J+2CUDSIN5epLSAdWB6LO0zOTIDNy9gqXAQ70UzeXn2b9jPRrhmGe K1+nWoAWa6F4cpGpUZwG+ZU3FPMID293bfJ+v2fLYtt3GY4kB8LmauJw4+1sPzohHV1m nchRQHnk6MKupPTMBZ94X3PWd97T/kPhvuksrGDk7+y8wyrKB4Ii+jLs0jWzO/ioNq0R h3ptCpeUeqKHjXM8cbOIUjxvhoK4pzD/R9+GaO9K2Ikwaw2x3ya2IcZax+HAIQOsDEnB cXowCASl2tZxLIy2K03CHg2hWNSiDkPi19mTMepOTjKB+wAzFWw5fB5NlbxdCCaPwilh Bg2w== 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=onJnQ9sf1KkUP+vU7AzX97/F4q8yd1pXcTcL9EjsHtM=; b=DSUmF0q93bI1m6KS7XNtOwwjaY0tOuesH+ekd5nhs+kkjRXACcVmTtIuQthk7yVcd5 SmGa3JhxzNptaneiOG2wLl4VL0CeoQBl0Fzt43IU5rLt5hQSRIZ5yBz4T6lQ3Sd2XChx vJnnTIUkqkPuhx0zC5p7KO02JKBmrSRv3oK5U5F4/Lh4GCOTf+Wn1xoEhDYN7vmbjmQs rTSWYJdukTH8Gudh3fQVZXNateDw2ESN05eyxqBvWQU89GJ81P3db03idG8HmWVueP2m 6RytivW+ZBKfdZ+FRWrGySKUyfKkQ/FeAwn8BisS9oCN6nP/ojkn33Ia+ACfT5n48KCA 3lRw== X-Gm-Message-State: AKS2vOzoZLOC1W5wnlkHDEvxk+XhYE56KXwUiqo1UiN5V+raMSVZJ6y5 WgECFGp8whpxr90AduOhI6QP/pAHrLlZ X-Received: by 10.176.10.13 with SMTP id q13mr5790276uah.54.1498240590977; Fri, 23 Jun 2017 10:56:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.138 with HTTP; Fri, 23 Jun 2017 10:56:30 -0700 (PDT) In-Reply-To: <361ef8798df34e4bb5bf8a46d43ce01c@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <149218146333.15800.10260233763572420696.idtracker@ietfa.amsl.com> <8854FBBB-F70C-4D1C-A272-1CFF983E7EB9@vigilsec.com> <7b1f3a6a-c7cd-c725-460b-c489fb957bc4@comodo.com> <361ef8798df34e4bb5bf8a46d43ce01c@ustx2ex-dag1mb1.msg.corp.akamai.com> From: William Conner Date: Fri, 23 Jun 2017 12:56:30 -0500 Message-ID: To: "Salz, Rich" Cc: Rob Stradling , Brian Smith , Russ Housley , SPASM Content-Type: multipart/alternative; boundary="f403045e86463727560552a452d9" Archived-At: Subject: Re: [lamps] [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jun 2017 17:56:34 -0000 --f403045e86463727560552a452d9 Content-Type: text/plain; charset="UTF-8" Thank you all for your comments. My apologies for the delayed response. An updated version is now available at https://tools.ietf.org/html/draft-wconner-blake2sigs-01. A couple of notes: 1. We're fine with switching the OIDs to a different arc. 2. Although we understand the concerns about PKCS #1 v1.5 signatures, we've decided to keep them in this version of the proposal to ensure that our coverage is as complete as the signature algorithm OIDs registered by NIST for SHA-3. http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html#DSA William On Tue, May 2, 2017 at 7:47 AM, Salz, Rich wrote: > > I suggest inviting Symantec to donate some 1.3.101. OIDs for draft- > > wconner-blake2sigs too. > > Work is in progress to turn the arc over to IETF / IANA / someone-like-us. > --f403045e86463727560552a452d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for your comments.=C2=A0 My apologies for th= e delayed response.

An updated version is now available = at=C2=A0https://tools.ietf.org/html/draft-wconner-blake2sigs-01.
A couple of notes:

1.=C2=A0 We're = fine with switching the OIDs to a different arc.

2= .=C2=A0 Although we understand the concerns about PKCS #1 v1.5 signatures, = we've decided to keep them in this version of the proposal to ensure th= at our coverage is as complete as the signature algorithm OIDs registered b= y NIST for SHA-3.


=

William
On Tue, May 2, 2017 at 7:47 AM, Salz, Rich <rsa= lz@akamai.com> wrote:
> I suggest inviting Symantec to donate some 1.3.101.<x&g= t; OIDs for draft-
> wconner-blake2sigs too.

Work is in progress to turn the arc over to IETF / IANA / someone-li= ke-us.

--f403045e86463727560552a452d9-- From nobody Fri Jun 23 12:01:25 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 C2099128C83; Fri, 23 Jun 2017 12:01:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149824447774.17302.16123684264254766730@ietfa.amsl.com> Date: Fri, 23 Jun 2017 12:01:17 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5280-i18n-update-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jun 2017 19:01:18 -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 : Internationalization Updates to RFC 5280 Author : Russ Housley Filename : draft-ietf-lamps-rfc5280-i18n-update-02.txt Pages : 8 Date : 2017-06-23 Abstract: These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5280-i18n-update-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5280-i18n-update-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5280-i18n-update-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 Fri Jun 23 12:04:01 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 26EFA128BBB for ; Fri, 23 Jun 2017 12:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 czkQt4VLgl-X for ; Fri, 23 Jun 2017 12:03:56 -0700 (PDT) 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 160E7128BB6 for ; Fri, 23 Jun 2017 12:03:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 731B930048E for ; Fri, 23 Jun 2017 15:03:55 -0400 (EDT) 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 0g8KuFP4QFwV for ; Fri, 23 Jun 2017 15:03:54 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 81B70300438 for ; Fri, 23 Jun 2017 15:03:54 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 23 Jun 2017 15:03:54 -0400 References: <149824447774.17302.16123684264254766730@ietfa.amsl.com> To: LAMPS In-Reply-To: <149824447774.17302.16123684264254766730@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc5280-i18n-update-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jun 2017 19:03:58 -0000 When doing the Shepherd write-up, Phillip found a few minor things that = needed correction. The biggest is the addition of the pre-RFC5378 = boilerplate. Russ > 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. >=20 > Title : Internationalization Updates to RFC 5280 > Author : Russ Housley > Filename : draft-ietf-lamps-rfc5280-i18n-update-02.txt > Pages : 8 > Date : 2017-06-23 >=20 > Abstract: > These updates to RFC 5280 provide clarity on the handling of > Internationalized Domain Names (IDNs) and Internationalized Email > Addresses in X.509 Certificates. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-rfc5280-i18n-update-02 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5280-i18n-update= -02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5280-i18n-update-0= 2 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 23 17:11:12 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 0D50012EAAE; Fri, 23 Jun 2017 17:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spasm@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282604.7840.10750911559908648589.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:06 -0700 Archived-At: Subject: [lamps] lamps - Requested session has been scheduled for IETF 99 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 24 Jun 2017 00:07:06 -0000 Dear Russ Housley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lamps Session 1 (1:00:00) Monday, Afternoon Session III 1740-1840 Room Name: Karlin I/II size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: rtcweb ace acme openpgp stir ipwave tls sipbrandy sidrops saag perc quic curdle Second Priority: cfrg dprive ecrit oauth sacm mile modern radext Third Priority: mtgvenue People who must be present: Russ Housley Eric Rescorla Sean Turner Jim Schaad Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 23 17:19:07 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 80B87129B33 for ; Fri, 23 Jun 2017 17:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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=eff.org 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 mjTjhkpgnA06 for ; Fri, 23 Jun 2017 17:17:52 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8863D129B47 for ; Fri, 23 Jun 2017 17:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=A0MlvBuxiNGuLtxUNW5lf+dWHs311d1ahhJF4p2S34w=; b=PFOyNx7zgzjeOOz4bbL0hct4XmPwq9ucxLL4yoXARD3TBk5YvAn0vmLINPq3QTajGOV2IxwEsvd7bFUF0xsFDPCyyZJ5NY+rYj3FqGxZ4keVk1dSZyg4KCjFZUMkWmf67i6/KOOwPAAJxW4BYAAJxTTZqe9BEc/xdjb/m+fhZG8=; Received: ; Fri, 23 Jun 2017 17:15:05 -0700 To: Phillip Hallam-Baker , "Salz, Rich" Cc: SPASM , Rob Stradling References: <3c0da781-2586-647e-7332-c7233dd9570d@eff.org> <021b346f-966e-377b-a242-73d3613921b0@eff.org> <81cfd21c-e46a-29a3-d667-6e1b4a4bbbca@eff.org> <817edd56793e454aaa9759ba6ba03809@usma1ex-dag1mb1.msg.corp.akamai.com> From: Jacob Hoffman-Andrews Message-ID: Date: Fri, 23 Jun 2017 17:15:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3A7291191E13A2FE16E9A639" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] [Spasm] Erratum 4988 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 24 Jun 2017 00:17:59 -0000 This is a multi-part message in MIME format. --------------3A7291191E13A2FE16E9A639 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This version looks good to me. Good catch to whoever pointed out Unbound's hard limit. And thanks to Phillip for pushing this through multiple revisions. Any other thoughts from the list? On 06/22/2017 12:52 PM, Phillip Hallam-Baker wrote: > > In response to comments by a non list subscriber: > > > s/follow the CNAME record/follow the CNAME record chain > > s/ten or fewer/8 or fewer/ > > > The first is just for clarity and the second is because it turns out > that unbound has a hard limit of 8 CNAME records to follow in a chain > which provides a justification for a number that was previously arbitrary. > > > If there is a revision of RFC1035 to specify a limit it will certainly > follow unbound unless there is another library in common use with a > different limit. > > > > Corrected Text > > -------------- > > Let CAA(X) be the record set returned in response to performing a CAA > > record query on the label X, P(X) be the DNS label immediately above > > X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME > > alias record chain specified at the label X. > > > > o If CAA(X) is not empty, R(X) = CAA (X), otherwise > > > > o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = > > CAA(A(X)), otherwise > > > > o If X is not a top-level domain, then R(X) = R(P(X)), otherwise > > > > o R(X) is empty. > > > > Thus, when a search at node X returns a CNAME record, the CA will > > follow the CNAME record chain to its target. If the target label > > contains a_ _CAA record, it is returned. > > > ​O​ > therwise, the CA continues the search at > > the parent of node X. > > > > Note that the search does not include the parent of a target of a > > CNAME record (except when the CNAME points back to its own path). > > > > To prevent resource exhaustion attacks, CAs should limit the length of > > CNAME chains that are accepted. However CAs MUST process CNAME > > chains that contain 8 or fewer CNAME records. > > > On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker > > wrote: > > The RFC Editor has deleted all three of the existing errata. I > would like for the next errata to be the very last. > > > > Could people read, review and state if this works for them? > > ​ This text is the same as the one I posted to CABForum earlier > with the one exception being that I capitalized Otherwise in the > place it needed it.​ > > > > > Original Text > > ------------- > > Let CAA(X) be the record set returned in response to performing > a CAA > > record query on the label X, P(X) be the DNS label immediately > above > > X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME > > alias record specified at the label X. > > > > o If CAA(X) is not empty, R(X) = CAA (X), otherwise > > > > o If A(X) is not null, and R(A(X)) is not empty, then R(X) = > > R(A(X)), otherwise > > > > o If X is not a top-level domain, then R(X) = R(P(X)), otherwise > > > > o R(X) is empty. > > > > > > Corrected Text > > -------------- > > Let CAA(X) be the record set returned in response to performing > a CAA > > record query on the label X, P(X) be the DNS label immediately > above > > X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME > > alias record chain specified at the label X. > > > > o If CAA(X) is not empty, R(X) = CAA (X), otherwise > > > > o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = > > CAA(A(X)), otherwise > > > > o If X is not a top-level domain, then R(X) = R(P(X)), otherwise > > > > o R(X) is empty. > > > > Thus, when a search at node X returns a CNAME record, the CA will > > follow the CNAME record to its target. If the target label > contains a > > CAA record, it is returned. > > ​O​ > therwise, the CA continues the search at > > the parent of node X. > > > > Note that the search does not include the parent of a target of a > > CNAME record (except when the CNAME points back to its own path). > > > > To prevent resource exhaustion attacks, CAs should limit the > length of > > CNAME chains that are accepted. However CAs MUST process CNAME > > chains that contain ten or fewer CNAME records. > > > > Processing for DNAME is exactly the same as for CNAME. Note that > since > > DNAME records are implemented by creating the corresponding CNAME > > records on the fly, it is only necessary for DNAME records to appear > > on the wire for purposes of DNSSEC. > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --------------3A7291191E13A2FE16E9A639 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This version looks good to me. Good catch to whoever pointed out Unbound's hard limit. And thanks to Phillip for pushing this through multiple revisions. Any other thoughts from the list?

On 06/22/2017 12:52 PM, Phillip Hallam-Baker wrote:

In response to comments by a non list subscriber:


s/follow the CNAME record/follow the CNAME record chain

s/ten or fewer/8 or fewer/


The first is just for clarity and the second is because it turns out that unbound has a hard limit of 8 CNAME records to follow in a chain which provides a justification for a number that was previously arbitrary.


If there is a revision of RFC1035 to specify a limit it will certainly follow unbound unless there is another library in common use with a different limit.



Corrected Text

--------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record chain specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =

      CAA(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

  Thus, when a search at node X returns a CNAME record, the CA will

  follow the CNAME record chain to its target. If the target label 

  contains a CAA record, it is returned.

​O​
therwise, the CA continues the search at

  the parent of node X.

 

  Note that the search does not include the parent of a target of a

  CNAME record (except when the CNAME points back to its own path).

 

 To prevent resource exhaustion attacks, CAs should limit the length of

  CNAME chains that are accepted. However CAs MUST process CNAME

  chains that contain 8 or fewer CNAME records.


On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

The RFC Editor has deleted all three of the existing errata. I would like for the next errata to be the very last.

 

Could people read, review and state if this works for them?

​ This text is the same as the one I posted to CABForum earlier with the one exception being that I capitalized Otherwise in the place it needed it.​


 

Original Text

-------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =

      R(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

 

Corrected Text

--------------

   Let CAA(X) be the record set returned in response to performing a CAA

   record query on the label X, P(X) be the DNS label immediately above

   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME

   alias record chain specified at the label X.

 

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

 

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =

      CAA(A(X)), otherwise

 

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

 

   o  R(X) is empty.

 

  Thus, when a search at node X returns a CNAME record, the CA will

  follow the CNAME record to its target. If the target label contains a

  CAA record, it is returned.

​O​
therwise, the CA continues the search at

  the parent of node X.

 

  Note that the search does not include the parent of a target of a

  CNAME record (except when the CNAME points back to its own path).

 

 To prevent resource exhaustion attacks, CAs should limit the length of

  CNAME chains that are accepted. However CAs MUST process CNAME

  chains that contain ten or fewer CNAME records.

 

  Processing for DNAME is exactly the same as for CNAME. Note that since

  DNAME records are implemented by creating the corresponding CNAME

  records on the fly, it is only necessary for DNAME records to appear

  on the wire for purposes of DNSSEC.




_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--------------3A7291191E13A2FE16E9A639-- From nobody Sat Jun 24 10:16:47 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 8F082127B31 for ; Sat, 24 Jun 2017 10:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 EL6DPtqlM-Fv for ; Sat, 24 Jun 2017 10:16:45 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 F30A9126B71 for ; Sat, 24 Jun 2017 10:16:44 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5OHCGoe032277; Sat, 24 Jun 2017 18:16:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=OAMn4co0XGnvy3zbU3hoXkVSz6cHXTqJYHwGzlC3GgM=; b=SgfrfVvWWQBAivF+vK3Ze0NTN9C/ABtXK7a+U/CK9Z9jCgdWY/bzgG14L/TMTUnRe/YX a4RHaA4k+UkiyesyR8t8jLWAg/3BJ4f2M3e08pRTaJ+i2fKglwE+oFkacigG2ls95/bC zMjGrDgQDrCFOwVdOJC+zq9s+31+ixVSRRrW6Ec7FNwDI6Qq7LYrv0UWt1owf1blc7mb Z69+gUGlDUXM/Kv+vErRmnJnE0xf2JrDE7d3/5QAeqxn/gxlauhHR0IRtSswzYN+UusS fjIgCWgRJH1XYYsee+jHgWHZGISGnB4G3G+K9a086x6KED5rsS7HCZaFRxras5mWNMs1 1w== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2b9fm6aw29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 24 Jun 2017 18:16:43 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5OHGg9F009562; Sat, 24 Jun 2017 13:16:42 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b9kdugsqy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 24 Jun 2017 13:16:42 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 24 Jun 2017 12:16:41 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Sat, 24 Jun 2017 12:16:41 -0500 From: "Salz, Rich" To: Russ Housley CC: "spasm@ietf.org" Thread-Topic: OCSP Response Extension -- withdrawing Thread-Index: AdLtCz7jwLKFkxNVQVyQ7n+RLsfgzgAAky1A Date: Sat, 24 Jun 2017 17:16:40 +0000 Message-ID: <29e9e9e0dbf9440ba12f7dc8ad5344b4@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <73841ef12a8d4e9886a8d5af90493df4@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <73841ef12a8d4e9886a8d5af90493df4@ustx2ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.56] Content-Type: multipart/alternative; boundary="_000_29e9e9e0dbf9440ba12f7dc8ad5344b4ustx2exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-24_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706240317 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706240316 Archived-At: Subject: Re: [lamps] OCSP Response Extension -- withdrawing X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 24 Jun 2017 17:16:47 -0000 --_000_29e9e9e0dbf9440ba12f7dc8ad5344b4ustx2exdag1mb1msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (Sigh, it=92s still spasm =85) -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From: Salz, Rich Sent: Saturday, June 24, 2017 1:03 PM To: 'Russ Housley' Cc: 'lamps@ietf.org' Subject: OCSP Response Extension -- withdrawing At Chicago I presented on an OCSP Response Extension [1]. Just FYI, I=92m = no longer interested in driving this. If others are interested, I will hel= p. [1] https://www.ietf.org/proceedings/98/slides/slides-98-lamps-ocsp-revoke-= hint-00.pdf --_000_29e9e9e0dbf9440ba12f7dc8ad5344b4ustx2exdag1mb1msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

(Sigh, it=92s still spasm =85)

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

From: Salz, Rich
Sent: Saturday, June 24, 2017 1:03 PM
To: 'Russ Housley' <housley@vigilsec.com>
Cc: 'lamps@ietf.org' <lamps@ietf.org>
Subject: OCSP Response Extension -- withdrawing

 

At Chicago I presented on an OCSP Response Extension= [1].  Just FYI, I=92m no longer interested in driving this.  If = others are interested, I will help.

 

[1] https://www.ietf.org/proceedings/98/slides/slides-98-lamps-ocsp-revoke-hint= -00.pdf

 

--_000_29e9e9e0dbf9440ba12f7dc8ad5344b4ustx2exdag1mb1msgcorpak_-- From nobody Sun Jun 25 09:25: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 BA45D124D6C for ; Sun, 25 Jun 2017 09:25:22 -0700 (PDT) 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 bwCPHCeQz-0q for ; Sun, 25 Jun 2017 09:25:21 -0700 (PDT) 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 3E6081205D3 for ; Sun, 25 Jun 2017 09:25:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 58542300463 for ; Sun, 25 Jun 2017 12:25:20 -0400 (EDT) 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 Ed_5OobzfUDu for ; Sun, 25 Jun 2017 12:25:19 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 4FB5530002C for ; Sun, 25 Jun 2017 12:25:19 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sun, 25 Jun 2017 12:25:18 -0400 To: LAMPS X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 25 Jun 2017 16:25:23 -0000 We have almost finished the last document under the current charter. We = will beed to deal with any concerns raised by the IESG, but we should = starts drafting the next version of the charter while that is happening. = In Chicago, we talked about several possible topics for the re-charter: 4c) OCSP response extension for revocation hint text (Rich) Rich withdrew his support for this one. Unless someone else wants to = step in, this one will be dropped. 4b) Updates to CAA for RFC Erratum 4514 (Phill) HUM: Consensus in the room to suggest this for a future LAMPS WG = charter. Please propose a paragraph for the charter. 4a) Adding SHA3 to PKIX and S/MIME (Sean) HUM: Many people in the room to suggest this as a topic for a future LAMPS WG charter; however, a significant number thought it should not be done. Many people thought that SHA-256, SHA-384, and SHA-512 filled this need. = If you would like to see it move forward, please propose a paragraph = for the charter. Are there any other topics that someone would like to raise now? All = three of the above topics had at least one document to support them. = So, new topics should come with an Internet-Draft or a promise of one = before the I-D cutoff for Prague. Russ From nobody Mon Jun 26 05:25: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 7DCB6129B46 for ; Mon, 26 Jun 2017 05:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] 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 I1iWsiJxtEfw for ; Mon, 26 Jun 2017 05:25:10 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 54BE1129B42 for ; Mon, 26 Jun 2017 05:25:09 -0700 (PDT) Received: (qmail 6632 invoked by uid 1004); 26 Jun 2017 12:25:07 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 26 Jun 2017 13:25:07 +0100 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 201706261325073610; Mon, 26 Jun 2017 13:25:07 +0100 To: LAMPS From: Rob Stradling Cc: Russ Housley , Eran Messeri Message-ID: <23fa70cd-d469-1cd6-e3cf-0ad798dfc7ee@comodo.com> Date: Mon, 26 Jun 2017 13:25:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lamps] CMS signed-data message digest calculation - seeking clarification X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 12:25:15 -0000 Hi. I'm not sure if this is the best venue to ask questions about RFC5652, so please redirect me if appropriate. Context: In Certificate Transparency v2 (6962-bis) we're defining precertificates as CMS signed-data objects. The eContent will be a TBSCertificate, so to avoid the signature being a valid X.509 certificate signature we're requiring "signedAttrs" to be present. https://tools.ietf.org/html/rfc5652#section-5.4 explains how to compute the message digest on "the content together with the signed attributes". However, it seems that the "together with" part is underspecified. The first paragraph makes sense... 'In either case, the initial input to the message digest calculation process is the "value" of the encapsulated content being signed.' ...but, in the second paragraph, that "initial input" seems to be discarded and not actually used... 'The result of the message digest calculation process depends on whether the signedAttrs field is present. ... When the field is present, however, the result is the message digest of the complete DER encoding of the SignedAttrs value contained in the signedAttrs field.' Shall I file an erratum to propose changing that sentence to something along the lines of... 'When the field is present, however, the result is the message digest of: the initial input concatenated with the complete DER encoding of the SignedAttrs value contained in the signedAttrs field.' ? Or have I misunderstood something? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jun 26 06:06: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 09D1B129B66 for ; Mon, 26 Jun 2017 06:06:58 -0700 (PDT) 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 aeHlY7iP4nLq for ; Mon, 26 Jun 2017 06:06:56 -0700 (PDT) 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 01627129B5B for ; Mon, 26 Jun 2017 06:06:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 58E7830057A for ; Mon, 26 Jun 2017 09:06:55 -0400 (EDT) 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 ZMI_rQ5xsuoQ for ; Mon, 26 Jun 2017 09:06:52 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 070A130056B; Mon, 26 Jun 2017 09:06:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <23fa70cd-d469-1cd6-e3cf-0ad798dfc7ee@comodo.com> Date: Mon, 26 Jun 2017 09:06:55 -0400 Cc: LAMPS , Eran Messeri Content-Transfer-Encoding: quoted-printable Message-Id: References: <23fa70cd-d469-1cd6-e3cf-0ad798dfc7ee@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] CMS signed-data message digest calculation - seeking clarification X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 13:06:58 -0000 > On Jun 26, 2017, at 8:25 AM, Rob Stradling = wrote: >=20 > Hi. I'm not sure if this is the best venue to ask questions about = RFC5652, so please redirect me if appropriate. >=20 > Context: In Certificate Transparency v2 (6962-bis) we're defining = precertificates as CMS signed-data objects. The eContent will be a = TBSCertificate, so to avoid the signature being a valid X.509 = certificate signature we're requiring "signedAttrs" to be present. >=20 > https://tools.ietf.org/html/rfc5652#section-5.4 explains how to = compute the message digest on "the content together with the signed = attributes". However, it seems that the "together with" part is = underspecified. >=20 > The first paragraph makes sense... > 'In either case, the initial input to the message > digest calculation process is the "value" of the encapsulated = content > being signed.' >=20 > ...but, in the second paragraph, that "initial input" seems to be = discarded and not actually used... > 'The result of the message digest calculation process depends on > whether the signedAttrs field is present. > ... > When the field is present, however, the result is the message > digest of the complete DER encoding of the SignedAttrs value > contained in the signedAttrs field.' >=20 > Shall I file an erratum to propose changing that sentence to something = along the lines of... > 'When the field is present, however, the result is the message > digest of: the initial input concatenated with the complete DER > encoding of the SignedAttrs value contained in the signedAttrs > field.' > ? >=20 > Or have I misunderstood something? Does this bit os pseudo-code help? IF (signed attributes are absent) THEN md =3D Hash(content) ELSE message-digest attribute =3D Hash(content); md =3D Hash(DER(SignedAttributes)) Sign(md) Russ= From nobody Mon Jun 26 06: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 76F39129B7D for ; Mon, 26 Jun 2017 06:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] 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 ymeG8VORuK_B for ; Mon, 26 Jun 2017 06:29:27 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 6BFC5129B73 for ; Mon, 26 Jun 2017 06:29:27 -0700 (PDT) Received: (qmail 25567 invoked by uid 1004); 26 Jun 2017 13:29:25 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 26 Jun 2017 14:29:25 +0100 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 201706261429253097; Mon, 26 Jun 2017 14:29:25 +0100 To: Russ Housley Cc: LAMPS , Eran Messeri References: <23fa70cd-d469-1cd6-e3cf-0ad798dfc7ee@comodo.com> From: Rob Stradling Message-ID: Date: Mon, 26 Jun 2017 14:29:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] CMS signed-data message digest calculation - seeking clarification X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 13:29:32 -0000 On 26/06/17 14:06, Russ Housley wrote: > >> On Jun 26, 2017, at 8:25 AM, Rob Stradling wrote: >> >> Hi. I'm not sure if this is the best venue to ask questions about RFC5652, so please redirect me if appropriate. >> >> Context: In Certificate Transparency v2 (6962-bis) we're defining precertificates as CMS signed-data objects. The eContent will be a TBSCertificate, so to avoid the signature being a valid X.509 certificate signature we're requiring "signedAttrs" to be present. >> >> https://tools.ietf.org/html/rfc5652#section-5.4 explains how to compute the message digest on "the content together with the signed attributes". However, it seems that the "together with" part is underspecified. >> >> The first paragraph makes sense... >> 'In either case, the initial input to the message >> digest calculation process is the "value" of the encapsulated content >> being signed.' >> >> ...but, in the second paragraph, that "initial input" seems to be discarded and not actually used... >> 'The result of the message digest calculation process depends on >> whether the signedAttrs field is present. >> ... >> When the field is present, however, the result is the message >> digest of the complete DER encoding of the SignedAttrs value >> contained in the signedAttrs field.' >> >> Shall I file an erratum to propose changing that sentence to something along the lines of... >> 'When the field is present, however, the result is the message >> digest of: the initial input concatenated with the complete DER >> encoding of the SignedAttrs value contained in the signedAttrs >> field.' >> ? >> >> Or have I misunderstood something? > > > Does this bit os pseudo-code help? > > IF (signed attributes are absent) > THEN md = Hash(content) > ELSE message-digest attribute = Hash(content); > md = Hash(DER(SignedAttributes)) > > Sign(md) > > Russ Aha. Thanks Russ. Makes perfect sense now. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jun 26 09:11:28 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 D07BF12EA58 for ; Mon, 26 Jun 2017 09:11:26 -0700 (PDT) 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=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 pJoncLn-J9Ag for ; Mon, 26 Jun 2017 09:11:25 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 54E27129B38 for ; Mon, 26 Jun 2017 09:11:25 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id r125so3240659vkf.1 for ; Mon, 26 Jun 2017 09:11:25 -0700 (PDT) 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 :cc; bh=UsaURl1ETxKCvm0VvkSLh4ZPky2xRw83vThdezshi88=; b=PzExG6tu1hX/7IzMMFgst/dOqgzqwuD+H1zTmi2Rj1GCNPbSukRuOqiUOSLPy2GlHJ d9BFx3R1/AUBP3KxeOK8TlUcr5N2vtv4dR9YccrSAOgLS+cRfrRNcCehQl5xJmazpBJm 6vKe0b/npU6lvHOvWDJ6x3rRlVGRm2xvxuvu4kXrv+nXb/2oOMhdCFbL5TimsPMbFmWP 0QVc40lP7UfzX+gWLhX8Hr9NFMZPSfeVrWkfizu2OzkDwCD/qIkcTqRohUDbE7xJGQTh Yl5OO6MkPgPZ+PuipOIztvYREkQ196Zocl7iIJJxL3qh/Ou5Mo0PbSgJBwGKMjp8N+D0 95eg== 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=UsaURl1ETxKCvm0VvkSLh4ZPky2xRw83vThdezshi88=; b=MEWQ4LnMJ+5KGB6LL5nsRaoBmn6Gm7PDWq5PLA2zUyxZQOBo28gSV2HpvT0ZVcJ7CF v+YcOcAgUYC7TtfTOuPyDu8myfxUSpm80ZM9uoJvCDhlsxS4Rx4AypdUY9Wkt7xSn/5I 8rZuy50W54abgET+4NTgFRW3O/6kJrsQlcZaC4a5I0szpBrvb6mk7HnhcqqlFpnn0JaV siwJZGjdqAJ0rhTEWXmXlboiafqlnUpU6hgFoiOj5OGlbezf3jD6mHstySiDgDDPEGDm rsTR0G7aaF6oCCBUzqmZZKk4a8jwNsTzgvbAIlZ2XpjSA7g35sPU7yug0+QU1peh69XJ 8YAw== X-Gm-Message-State: AKS2vOy8dd33xtfwLmoKG0qtOMWEGwJ/6tsS+W9+p4vMcF1EHJbYjS4L wrzKY1NYsWj9ruDMwGttc/Q1t43LIH+iwdA= X-Received: by 10.31.165.210 with SMTP id o201mr511280vke.37.1498493484133; Mon, 26 Jun 2017 09:11:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.138 with HTTP; Mon, 26 Jun 2017 09:11:23 -0700 (PDT) In-Reply-To: References: From: William Conner Date: Mon, 26 Jun 2017 11:11:23 -0500 Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="001a11415beed263e00552df3390" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 16:11:27 -0000 --001a11415beed263e00552df3390 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 25, 2017 at 11:25 AM, Russ Housley wrote: > > 4a) Adding SHA3 to PKIX and S/MIME (Sean) > > HUM: Many people in the room to suggest this as a topic for a future > LAMPS WG charter; however, a significant number thought it should not > be done. > > Many people thought that SHA-256, SHA-384, and SHA-512 filled this need. > If you would like to see it move forward, please propose a paragraph for > the charter. > > > Are there any other topics that someone would like to raise now? All > three of the above topics had at least one document to support them. So, > new topics should come with an Internet-Draft or a promise of one before > the I-D cutoff for Prague. > > I would like to raise BLAKE2 for PKIX (draft-wconner-blake2sigs-01) as an alternative to 4a. William --001a11415beed263e00552df3390 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jun 25, 2017 at 11:25 AM, Russ Housley <housley@vigilsec.co= m> wrote:
draft-wconner-blake2sigs-01) as an alternative to 4a.

William
=C2=A0
=
--001a11415beed263e00552df3390-- From nobody Mon Jun 26 09:17: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 D950812EAED for ; Mon, 26 Jun 2017 09:17:19 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 7R6SleIm_VKj for ; Mon, 26 Jun 2017 09:17:18 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4638412EAE7 for ; Mon, 26 Jun 2017 09:17:18 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5QGH7gh018970; Mon, 26 Jun 2017 17:17:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=gscvFYEiTSvLosfIzHzuZKE7/yuwwulaszFrTa3nGi4=; b=UcUXRIcgQ++jWQOIganaraLlfIT8+vJh+wJItuWhUqsTdPozEHgACane8Efo0oOzTynJ s/8ZA+tqRG9KjFv2YtM5PkFcVKjgEBGCtmLUnMmOSenosXgr9QLHkNaUcQYHH5m1pRvR Vkt955+HYBS6uut9ZW2SZ9Osl6U+k+2CBKbVHxlhVZv3XYwKKDeArZ/kxdMNX/vNt0EJ 0KQcBQ0TYuqcKilyJv1jGtm7wmqPM8xsRVlynXYbeQ4zV7mWprfJIXWubJ020/aXzLvE DocKSYr7QNb7KEwsHY8h+uSYDSXzOCZ/l7FkEdOgNGHd+RLctrkcNhkxOJ73/9SC9ANZ eQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2barexk68u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Jun 2017 17:17:14 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5QGGndp005754; Mon, 26 Jun 2017 12:17:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b9kdumwfh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 26 Jun 2017 12:17:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 26 Jun 2017 12:17:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 26 Jun 2017 12:17:11 -0400 From: "Salz, Rich" To: William Conner , Russ Housley CC: LAMPS Thread-Topic: [lamps] Recharter Discussion Thread-Index: AQHS7c+piGadg7oTPkeKQkzDVeF7q6I3lSSA//++B4A= Date: Mon, 26 Jun 2017 16:17:11 +0000 Message-ID: <8b1bc7cc35484678b96b3b8d9ed0350d@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-26_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706260273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-26_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706260273 Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jun 2017 16:17:20 -0000 PiBJIHdvdWxkIGxpa2UgdG8gcmFpc2UgQkxBS0UyIGZvciBQS0lYIChkcmFmdC13Y29ubmVyLWJs YWtlMnNpZ3MtMDEpIGFzIGFuIGFsdGVybmF0aXZlIHRvIDRhLg0KDQpXaGljaCBvbmU/ICBBcmVu J3QgYWxsIGZvdXIoPykgdmVyc2lvbnMgZGlmZmVyZW50Pw0K From nobody Tue Jun 27 06:06: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 2BA1D129B07 for ; Tue, 27 Jun 2017 06:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 KnrQpnQx5_kV for ; Tue, 27 Jun 2017 06:06:31 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 53E79129B06 for ; Tue, 27 Jun 2017 06:06:31 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id g40so17863312uaa.3 for ; Tue, 27 Jun 2017 06:06:31 -0700 (PDT) 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 :cc; bh=t7K0gouGh2FKqMPzR4BybxNW58anbxCb0BikjH+LO1s=; b=g6KS1NwreyrEwTKGTYs4g+oXFkBP7OC03nogEnipo/mzyvAOHN0GBbVSbwGBve/lqa w4xl1bGuSzIIHL4UHp7Q0Ze7Y0R5MI5mK7A8CoxhtCGbVQHaubYIJV5BZ7BoUswbvHgX bn1cv/DxgzFTr8csbFDhF3ENSL3kD70pbwaLNHLuVoov7QGNeTTq/SbAa/x6SIU1qNk4 +2yAHBJIINXDf0IPuGM9dLrohrS/2jeSOavRg8hY8n+k/7tHNiI3RglrMfWdiNmeoJuU nMuFQhHxXXJY1vMJYcJK+Up1FAD+W2FpWQ0VhnLQcphqtVVOz5kHtOl1X+ZPncQ9sg+e gITA== 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=t7K0gouGh2FKqMPzR4BybxNW58anbxCb0BikjH+LO1s=; b=b82ZLApBiYypgiSjZnUG5uacr9ouq89oNW38Dka5N7i7qn81iHN/1upb5uWyG9gctx 3p6qONtq3RKjiTgWIWaQNcWCYYVfv0n60mCPNLO9N9dh+O/UAGZ55zow4vLh4qx9WXli pyc8Gh10CYz5/EsQToMBC2F6btIorvJSbEq6MpPEAX9StMentTQq3mse2K4MpriOQVOI C3/fYIi/e0eKNlLFkDkFT1QGRpqZHaW6QT8oPAMMqf4LsnB4T9WcQSMRd+G3nIg/60zt pq0jSwVWYWzp5iVcyIVtPIcMIa0Ah0hkJrKb5b1fiJM9sulDj0UaY8IAb99xwnM+DNoi 7sMg== X-Gm-Message-State: AKS2vOwt2niBjKV8FZzdFvOEE54uj+ofKt6c6+XANq3+0tk544UPscWp 2uFYChIMeUPZkFxv4X8yq2ov43nkX8NHKf0= X-Received: by 10.176.7.70 with SMTP id h64mr2558273uah.134.1498568790258; Tue, 27 Jun 2017 06:06:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.138 with HTTP; Tue, 27 Jun 2017 06:06:29 -0700 (PDT) In-Reply-To: <8b1bc7cc35484678b96b3b8d9ed0350d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b1bc7cc35484678b96b3b8d9ed0350d@usma1ex-dag1mb1.msg.corp.akamai.com> From: William Conner Date: Tue, 27 Jun 2017 08:06:29 -0500 Message-ID: To: "Salz, Rich" Cc: Russ Housley , LAMPS Content-Type: multipart/alternative; boundary="94eb2c12339a6aa5e60552f0bc4a" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 27 Jun 2017 13:06:33 -0000 --94eb2c12339a6aa5e60552f0bc4a Content-Type: text/plain; charset="UTF-8" On Mon, Jun 26, 2017 at 11:17 AM, Salz, Rich wrote: > > I would like to raise BLAKE2 for PKIX (draft-wconner-blake2sigs-01) as > an alternative to 4a. > > Which one? Aren't all four(?) versions different? > Sorry, I seem to be missing something and don't quite understand what you're asking. Would you please elaborate? Thanks. --94eb2c12339a6aa5e60552f0bc4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 26, 2017 at 11:17 AM, Salz, Rich <rsalz@akamai.com><= /span> wrote:
> I wou= ld like to raise BLAKE2 for PKIX (draft-wconner-blake2sigs-01) as an altern= ative to 4a.

Which one?=C2=A0 Aren't all four(?) versions different?

Sorry, I seem to be missing something and don&#= 39;t quite understand what you're asking.=C2=A0 Would you please elabor= ate?=C2=A0 Thanks.=C2=A0

--94eb2c12339a6aa5e60552f0bc4a-- From nobody Tue Jun 27 06:36:13 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 7D5FD129B25 for ; Tue, 27 Jun 2017 06:36:12 -0700 (PDT) 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, 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=akamai.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 L3r40E-4zXxV for ; Tue, 27 Jun 2017 06:36:11 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 12007127078 for ; Tue, 27 Jun 2017 06:36:11 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5RDWqJj016563; Tue, 27 Jun 2017 14:36:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Bq3Z6sqYJg0RQt/b9XP7XB3zeoRpHnXDh5ZJph5m5JA=; b=URYqf8/rvEZ+z4T/0AI4xKrdc9W5LuCEzNBzF3O3R2YYDJSZw+I61qiDaNBXHVf60mUh rMVqbKrthPOuOlZPjllRmM34HO/T5mahDpyGr8oOBdftBH7/DhklQ1DmpTJXYt8DrbuM 2byedU3PwsHXG9hMVMQLXeAYECBCQmg+HoNKr1fVcFQdFnr9dSHdkUOTwgd1y+aIwKS0 gg7BoBVedPENquMx2Sifwi85ry2YwZ6FRNWfmnDtHV9c56IkQZnFxnoq+u2Ei2X1R6d9 FYJ9tMSMu5uADaPW9M0/kTDhUnz3hlij/o0B2/Cvu+qbu3nKFjJccMQJ0Xy5zBYY9Xw1 Gg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2bb82a4kyn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jun 2017 14:36:08 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5RDW9Kr019976; Tue, 27 Jun 2017 09:36:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b9kdusm0d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 27 Jun 2017 09:36:06 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 27 Jun 2017 06:36:06 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 27 Jun 2017 09:36:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 27 Jun 2017 09:36:05 -0400 From: "Salz, Rich" To: William Conner CC: Russ Housley , LAMPS Thread-Topic: [lamps] Recharter Discussion Thread-Index: AQHS7c+piGadg7oTPkeKQkzDVeF7q6I3lSSA//++B4CAAaClgP//w0Rg Date: Tue, 27 Jun 2017 13:36:05 +0000 Message-ID: <6bc898a652fb475589e2e7cfd082556e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8b1bc7cc35484678b96b3b8d9ed0350d@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.206] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-27_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706270219 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-27_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706270219 Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 27 Jun 2017 13:36:12 -0000 Pj4gSSB3b3VsZCBsaWtlIHRvIHJhaXNlIEJMQUtFMiBmb3IgUEtJWCAoZHJhZnQtd2Nvbm5lci1i bGFrZTJzaWdzLTAxKSBhcyBhbiBhbHRlcm5hdGl2ZSB0byA0YS4NCg0KPj4gV2hpY2ggb25lP8Kg IEFyZW4ndCBhbGwgZm91cig/KSB2ZXJzaW9ucyBkaWZmZXJlbnQ/DQoNCj4gU29ycnksIEkgc2Vl bSB0byBiZSBtaXNzaW5nIHNvbWV0aGluZyBhbmQgZG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCB3aGF0 IHlvdSdyZSBhc2tpbmcuwqAgV291bGQgeW91IHBsZWFzZSBlbGFib3JhdGU/wqAgVGhhbmtzLsKg DQoNCk15IGZhdWx0LiAgVGhlIHRleHQgb2YgeW91ciBkb2N1bWVudCBzYXlzIGl0IHVzZXMgMmIt NTEyIHF1aXRlIGV4cGxpY2l0bHkuICBQZXJoYXBzIHRoYXQgc2hvdWxkIGJlIHJlZmxlY3RlZCBp biB0aGUgdGl0bGU/DQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYmxha2UyYiBhbmQgYmxha2Uy cyBhcmUgdmVyeSBkaWZmZXJlbnQuICBNb3JlIHNvIHRoYW4sIHNheSwgUlNBNTEyIHZzIFJBUzIw NDguDQoNCg== From nobody Tue Jun 27 10:21: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 613F912EA7C for ; Tue, 27 Jun 2017 10:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 wjmCxXMINgYF for ; Tue, 27 Jun 2017 10:21:40 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 CE2AF12EAA9 for ; Tue, 27 Jun 2017 10:21:39 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id r62so30961075qkf.0 for ; Tue, 27 Jun 2017 10:21:39 -0700 (PDT) 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=hOQM6GC4rFnkcsyTT4oHciErMuTwMUGcwVFr5g9UnAU=; b=MNhBWmVr3e5S3IaiUFgNt7Ct4zw6LDXhb+BGbyx+yIrCjSDcbIappLLnUO1EXabNsP q9TFAIsdp9Er29q7NDDDNWjy3PnGVBPHw3Q5nMuDr7xqZc8J/ciot8fJo2yoAB3WcxOd mjf6s/WmJCVYjv/PKNZRnFqFJprRxnokZvyR7R8GIK3c1BjjioedwHzPELy6fc3LXNh6 4lIuuh1QN4+nqMzpVZVKxwW+SndpKddH7KJo9SfIBoZ9Rufl7nV1M/NS/BGH4f6FkK4N y2POvipp3lks1Pj0lDPmaO+Ahjc3HDKKRwYrRn7faUE4ID4l0+WhHHGxS4V/oj+kIwP3 k5pg== 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=hOQM6GC4rFnkcsyTT4oHciErMuTwMUGcwVFr5g9UnAU=; b=XVKS3B2bJKXezjChSBGapUouoVnz56KmUvW4WY7eC/Kz3c2dTaRyVgOfkG66SURvUM qd/xsTf26c2jhOfmNX5buuXpDrMsasy2pbzrXId/EjWpXtCfIVZ+muNMLdYp/9Qa93eW JgV/JCvO6lgc39WKvT3uRUbrEXQwXihKft2OXwnh9S9S2+y4E86NX9vLMK1MMWWDeSs/ fhuWYCsZ2mv3/WZ874NTyN2LD/IqJq1iowkgF6At40noDiywjLQi4t+azK/L69iflN0p GiBO9OsMyFNFyxNBoyNhFevuH3qroxuHrZeEBa+gTAiDeCp47s1Y6xQKg1rDBDhgDPSb VSFQ== X-Gm-Message-State: AKS2vOyJzlBNy+Do2c/0OYRk7l5xSJqCj4B5hl3lRCucanc1IUCRM1tF GHyp6SYItDFz/JBOrXmKroeIkLzP7w== X-Received: by 10.55.112.66 with SMTP id l63mr7965021qkc.56.1498584099012; Tue, 27 Jun 2017 10:21:39 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.140.102.79 with HTTP; Tue, 27 Jun 2017 10:21:38 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Tue, 27 Jun 2017 13:21:38 -0400 X-Google-Sender-Auth: aOceHdXPOJxhwD1cU36jttD6h4w Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="001a114fef34e348750552f44c9a" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 27 Jun 2017 17:21:42 -0000 --001a114fef34e348750552f44c9a Content-Type: text/plain; charset="UTF-8" X. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844 On Sun, Jun 25, 2017 at 12:25 PM, Russ Housley wrote: > We have almost finished the last document under the current charter. We > will beed to deal with any concerns raised by the IESG, but we should > starts drafting the next version of the charter while that is happening. > In Chicago, we talked about several possible topics for the re-charter: > > > 4c) OCSP response extension for revocation hint text (Rich) > > Rich withdrew his support for this one. Unless someone else wants to step > in, this one will be dropped. > > > 4b) Updates to CAA for RFC Erratum 4514 (Phill) > > HUM: Consensus in the room to suggest this for a future LAMPS WG charter. > Please propose a paragraph for the charter. > > > 4a) Adding SHA3 to PKIX and S/MIME (Sean) > > HUM: Many people in the room to suggest this as a topic for a future > LAMPS WG charter; however, a significant number thought it should not > be done. > > Many people thought that SHA-256, SHA-384, and SHA-512 filled this need. > If you would like to see it move forward, please propose a paragraph for > the charter. > > > Are there any other topics that someone would like to raise now? All > three of the above topics had at least one document to support them. So, > new topics should come with an Internet-Draft or a promise of one before > the I-D cutoff for Prague. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a114fef34e348750552f44c9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

X. Specify a discovery = mechanism for CAA records to replace the one described in RFC 6844

On Sun, Jun 25= , 2017 at 12:25 PM, Russ Housley <housley@vigilsec.com> w= rote:
We have almost finished the last do= cument under the current charter.=C2=A0 We will beed to deal with any conce= rns raised by the IESG, but we should starts drafting the next version of t= he charter while that is happening.=C2=A0 In Chicago, we talked about sever= al possible topics for the re-charter:


4c)=C2=A0 OCSP response extension for revocation hint text (Rich)

Rich withdrew his support for this one.=C2=A0 Unless someone else wants to = step in, this one will be dropped.


4b)=C2=A0 Updates to CAA for RFC Erratum 4514 (Phill)

HUM: Consensus in the room to suggest this for a future LAMPS WG charter.= =C2=A0 Please propose a paragraph for the charter.


4a)=C2=A0 Adding SHA3 to PKIX and S/MIME (Sean)

HUM: Many people in the room to suggest this as a topic for a future
=C2=A0 LAMPS WG charter; however, a significant number thought it should no= t
=C2=A0 be done.

Many people thought that SHA-256, SHA-384, and SHA-512 filled this need.=C2= =A0 If you would like to see it move forward, please propose a paragraph fo= r the charter.


Are there any other topics that someone would like to raise now?=C2=A0 All = three of the above topics had at least one document to support them.=C2=A0 = So, new topics should come with an Internet-Draft or a promise of one befor= e the I-D cutoff for Prague.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--001a114fef34e348750552f44c9a-- From nobody Thu Jun 29 07:51: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 AB0C3131458 for ; Thu, 29 Jun 2017 07:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 MXgmaOeo2UAM for ; Thu, 29 Jun 2017 07:51:31 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 16835129AB8 for ; Thu, 29 Jun 2017 07:51:31 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id h22so54308575lfk.3 for ; Thu, 29 Jun 2017 07:51:30 -0700 (PDT) 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=GyzjJInU8JmC+f2/ZNO1a0eikulX+KaWMwNZSZOrlDE=; b=UUAjKl1xIgyZRaamAlKNl46y9ySdq+gHBqvlXNpEK3r3T/PXlLJtpNabzplsW4hU/x 5RRWi4lHw5+ooKMGcv8efmPEhjpwh+a9l2jHWA5be5gx4Q1eDws8a4AfV7HUE29imiXo Frzmi17IW0U1Y3oafbokG9nfy495mGD40JeoZTs4cZ7hb3Dy5meqZZ1pBfpyevmhLNu7 O0DoWapFy91Af2gTFl5X0duORrbbvi75q951ulCbCX/dHMphVYJcsKuqF0Cxp25mqkVN OgH5zKk3uTmCrioerBnz/AtHjOri2kPmjRkQRMjT0Q0ATyIkHIRlDV4IlQ71bisrWdkI Q/BA== 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=GyzjJInU8JmC+f2/ZNO1a0eikulX+KaWMwNZSZOrlDE=; b=k3l4Sh0g8W4fW1a4QKWuI70kDJ43BL1HaAxtY4HMoww83zanHgmmcR5QAoBVZ+JCCr m+Pg4v60E+xwIPe23ovEXq90znkWLkvbtIAOAWM5cowSPB8OsVCvZzyE/u9wfcmuKcoR ZXmFcxAF2470fQ1TPk0S4gTbir5MPdDXS8XlwL8KnjH2WHZoDBcY39MowtX+mPq/qlE2 aHtAFady4UWY9Al71OJGQ8hNqCH8LZVA3GgGfl2dy1IGPmu85Mn04+wjN904cgft/2qa mGqqcaNa6KJU12EHula2RQphCxfBMR/nypBDnPGvE0o0xQSIAG2gH966zXOtvBSONv8q uvsA== X-Gm-Message-State: AKS2vOwA6Gbgz0UJ68Z3LJOO8GzY8rwo1J7xfN06ZDEuUm5he3ISQAEf a4cIGvAW5oi9Eqt8f294DQdBy55GHyI6 X-Received: by 10.46.77.84 with SMTP id a81mr5096380ljb.73.1498747889271; Thu, 29 Jun 2017 07:51:29 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Thu, 29 Jun 2017 07:51:28 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Thu, 29 Jun 2017 10:51:28 -0400 X-Google-Sender-Auth: ZGBXhhFWh7xySJ2tpVd25Ydi3ns Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="94eb2c1aac368c4b1105531a6fb6" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 14:51:33 -0000 --94eb2c1aac368c4b1105531a6fb6 Content-Type: text/plain; charset="UTF-8" I would like to suggest a new PKIX extension, the 'First Issued' attribute. This has been discussed many times but not actually implemented as far as I know. A certificate that was issued a year ago is much less likely to be fraudulent than one issued five minutes ago. While criminals could in theory apply for and stockpile large numbers of certificates, the takes planning and discipline and limits their options when responding to new security controls. A certificate issued with an expiry interval of 400 days will be less than a day old for only 0.25% of its lifetime. But if we move to 3 day certs, the certificate will be less than a day old for 33% of the time. The value of the certificate age indication is lost entirely. Adding a 'first issued' attribute would allow a CA to state when the first certificate was issued to the subject. Similar to the American Express 'member since' indication. I don't have a draft or text yet. But I can write them up if people are interested in doing this. --94eb2c1aac368c4b1105531a6fb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I w= ould like to suggest a new PKIX extension, the 'First Issued' attri= bute. This has been discussed many times but not actually implemented as fa= r as I know.

A certif= icate that was issued a year ago is much less likely to be fraudulent than = one issued five minutes ago. While criminals could in theory apply for and = stockpile large numbers of certificates, the takes planning and discipline = and limits their options when responding to new security controls.

A certificate issued with an expi= ry interval of 400 days will be less than a day old for only 0.25% of its l= ifetime. But if we move to 3 day certs, the certificate will be less than a= day old for 33% of the time. The value of the certificate age indication i= s lost entirely.

Adding a= 'first issued' attribute would allow a CA to state when the first = certificate was issued to the subject. Similar to the American Express '= ;member since' indication.

I don't have a draft or text yet. But I can write them up if peop= le are interested in doing this.

--94eb2c1aac368c4b1105531a6fb6-- From nobody Thu Jun 29 08:05:25 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 E203D129C2A for ; Thu, 29 Jun 2017 08:05:23 -0700 (PDT) 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, HTML_MESSAGE=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 85RzwjEUVfOZ for ; Thu, 29 Jun 2017 08:05:22 -0700 (PDT) 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 96A86129B21 for ; Thu, 29 Jun 2017 08:05:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0EB5A3004D8 for ; Thu, 29 Jun 2017 11:05:22 -0400 (EDT) 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 quJEFIZ3Usot for ; Thu, 29 Jun 2017 11:05:20 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 8108730023A; Thu, 29 Jun 2017 11:05:20 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BA5C92AE-E325-4DFF-A6B9-62DDC9518B21" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 11:05:20 -0400 In-Reply-To: Cc: LAMPS To: Phillip Hallam-Baker References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 15:05:24 -0000 --Apple-Mail=_BA5C92AE-E325-4DFF-A6B9-62DDC9518B21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Phill: I just want to make sure I understand your proposal. I can see that a = renew does not change the date in the first-issued extension. Does a = rekey change it? Russ > On Jun 29, 2017, at 10:51 AM, Phillip Hallam-Baker = wrote: >=20 > I would like to suggest a new PKIX extension, the 'First Issued' = attribute. This has been discussed many times but not actually = implemented as far as I know. >=20 > A certificate that was issued a year ago is much less likely to be = fraudulent than one issued five minutes ago. While criminals could in = theory apply for and stockpile large numbers of certificates, the takes = planning and discipline and limits their options when responding to new = security controls. >=20 > A certificate issued with an expiry interval of 400 days will be less = than a day old for only 0.25% of its lifetime. But if we move to 3 day = certs, the certificate will be less than a day old for 33% of the time. = The value of the certificate age indication is lost entirely. >=20 > Adding a 'first issued' attribute would allow a CA to state when the = first certificate was issued to the subject. Similar to the American = Express 'member since' indication. >=20 > I don't have a draft or text yet. But I can write them up if people = are interested in doing this. >=20 --Apple-Mail=_BA5C92AE-E325-4DFF-A6B9-62DDC9518B21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Phill:

I = just want to make sure I understand your proposal.  I can see that = a renew does not change the date in the first-issued extension. =  Does a rekey change it?

Russ


On Jun 29, 2017, at 10:51 AM, = Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I = would like to suggest a new PKIX extension, the 'First Issued' = attribute. This has been discussed many times but not actually = implemented as far as I know.

A = certificate that was issued a year ago is much less likely to be = fraudulent than one issued five minutes ago. While criminals could in = theory apply for and stockpile large numbers of certificates, the takes = planning and discipline and limits their options when responding to new = security controls.

A certificate issued = with an expiry interval of 400 days will be less than a day old for only = 0.25% of its lifetime. But if we move to 3 day certs, the certificate = will be less than a day old for 33% of the time. The value of the = certificate age indication is lost entirely.

Adding a 'first issued' attribute would allow = a CA to state when the first certificate was issued to the subject. = Similar to the American Express 'member since' indication.

I = don't have a draft or text yet. But I can write them up if people are = interested in doing this.


= --Apple-Mail=_BA5C92AE-E325-4DFF-A6B9-62DDC9518B21-- From nobody Thu Jun 29 08:16:36 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 5D88312EA81 for ; Thu, 29 Jun 2017 08:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 xlJfp9B9MWhU for ; Thu, 29 Jun 2017 08:16:32 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 5B719129B18 for ; Thu, 29 Jun 2017 08:16:32 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id h22so54765507lfk.3 for ; Thu, 29 Jun 2017 08:16:32 -0700 (PDT) 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=YFCv+38dVfBapINu2oN592oY3IOgVPtK6tNGSR0hszk=; b=PfPQypPBV8X6rYjGHd7XOyGIki8EF4W/RH6lSuiXNMZfvTsUNcZ3+6upqA9WfDLJGi noC0rg1euSId1n+qLIRWfgEc79ukvgE+MkhN9+R2KnBkTXbBGrrW7ELdRTVtVvhvuY4F 6m7mnSKghDVJnFn4FsiLElv/wB6EzWJS+suc4FOFHCC4LcDP/6LbqIvqNxV5L5YV35SI 2p9fjEJWbc0DmeHRRdd8XMX3a3x4gUUlcsQB54KpLrHdpIjz0gbwzfkbL9Px/jHnW/45 SS3Ql+CsvWD9eR1kfovbbGa0GNewSDWRGId6V8WXkL5FpKI84nWLeamSLGCALvcSDQOI jOsg== 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=YFCv+38dVfBapINu2oN592oY3IOgVPtK6tNGSR0hszk=; b=dYNwMgLF6WQhSr1jVGz4E4bf7Emb2s2zxsAfCzqfvtPWmpRseZlnDq006kWaTYm4du kBXkBPYJqjR+sbGX7bQlP/k4EHlWpFdxS3xTG4MjQI/SAcLWFU27eFbRg2dBc82edKjO McB5tJO2FuY4MxxkrmDy0+8OcDZ5wsjVr3Xy323tmTA3rlHfdg9E+cLXbzEuSv1i10we zgZrzr6CQWxGDK5cFAmniX9CYuB/g5bX2owrWLHWWe8MNQ9ThKMCw2VZ4uuvnImGviQN vy7YHfeWQGEN+txYt2oCi1xZjWTH1JG0nQPA8Rvo3tyPcvLbf/6582hqZtRmvpYnXDO/ D04Q== X-Gm-Message-State: AKS2vOyjGULhlSuW9IYjMwn63s1m+HUpRM+sEm3ksQK0zMyN6pFmHj/C TgqfpkY8sd4GT/ZmTMDO4twiCk2p6w== X-Received: by 10.46.22.22 with SMTP id w22mr4849246ljd.76.1498749390556; Thu, 29 Jun 2017 08:16:30 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Thu, 29 Jun 2017 08:16:29 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Thu, 29 Jun 2017 11:16:29 -0400 X-Google-Sender-Auth: 6RjJU5Fn0va1G8KgkAB9oC2OKng Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="f403045fb42808157305531ac96f" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 15:16:34 -0000 --f403045fb42808157305531ac96f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 29, 2017 at 11:05 AM, Russ Housley wrote= : > Phill: > > I just want to make sure I understand your proposal. I can see that a > renew does not change the date in the first-issued extension. Does a rek= ey > change it? > > Russ > =E2=80=8BGood question!=E2=80=8B =E2=80=8BThe simplest implementation to audit would have the date be for th= e key and thus change on rekey. But the most useful =E2=80=8Bimplementation would be to have the date corre= spond to the subject and we certainly do not want to discourage rekeying. That does leave open the question of whether changes in the subject name cause a break and whether a CA may use the earliest date at which any certificate was issued. There is something of a slippery slope here. I see two approaches 1) Be intentionally vague and kick the problem to TRANS and/or CABForum. 2) Limit the time to the time that CA issued a certificate to that subject name Part of the complexity here is that certificate issue on the enterprise side is not typically authenticated by means that are within PKIX or TRANS scope. --f403045fb42808157305531ac96f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Thu, Jun 29, 2017 at 11:05 AM, Russ Housley <housley@vigilsec.com= > wrote:
P= hill:

I just want to make sure I understand your proposa= l.=C2=A0 I can see that a renew does not change the date in the first-issue= d extension.=C2=A0 Does a rekey change it?

Russ

=E2=80=8BGood question!=E2=80=8B


=E2=80=8BThe simple= st implementation to audit would have the date be for the key and thus chan= ge on rekey.
But the most= useful =E2=80=8Bimplementation would be to have the date correspond to the= subject and we certainly do not want to discourage rekeying.

That does leave open the question of w= hether changes in the subject name cause a break and whether a CA may use t= he earliest date at which any certificate was issued.


There is something of a slippery slope here. I see two= approaches
1) Be intenti= onally vague and kick the problem to TRANS and/or CABForum.

2) Limit the time to the time that CA is= sued a certificate to that subject name


Part of the complexity here is that certificate issue on the enterpris= e side is not typically authenticated by means that are within PKIX or TRAN= S scope.

--f403045fb42808157305531ac96f-- From nobody Thu Jun 29 08:21: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 2509113146A for ; Thu, 29 Jun 2017 08:21:53 -0700 (PDT) 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, HTML_MESSAGE=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 HxrtRFhSfOjY for ; Thu, 29 Jun 2017 08:21:51 -0700 (PDT) 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 BAB621300E7 for ; Thu, 29 Jun 2017 08:21:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2BB6D30044F for ; Thu, 29 Jun 2017 11:21:51 -0400 (EDT) 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 JLX6sluUPCr0 for ; Thu, 29 Jun 2017 11:21:49 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 5E6033003FE; Thu, 29 Jun 2017 11:21:49 -0400 (EDT) From: Russ Housley Message-Id: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4818E20A-A15C-4D13-A523-B444CA4E7708" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 11:21:48 -0400 In-Reply-To: Cc: LAMPS To: Phillip Hallam-Baker References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 15:21:53 -0000 --Apple-Mail=_4818E20A-A15C-4D13-A523-B444CA4E7708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 29, 2017, at 11:16 AM, Phillip Hallam-Baker = wrote: >=20 > On Thu, Jun 29, 2017 at 11:05 AM, Russ Housley > wrote: > Phill: >=20 > I just want to make sure I understand your proposal. I can see that a = renew does not change the date in the first-issued extension. Does a = rekey change it? >=20 > Russ >=20 > =E2=80=8BGood question!=E2=80=8B >=20 >=20 > =E2=80=8BThe simplest implementation to audit would have the date be = for the key and thus change on rekey. >=20 > But the most useful =E2=80=8Bimplementation would be to have the date = correspond to the subject and we certainly do not want to discourage = rekeying. >=20 > That does leave open the question of whether changes in the subject = name cause a break and whether a CA may use the earliest date at which = any certificate was issued. >=20 >=20 > There is something of a slippery slope here. I see two approaches >=20 > 1) Be intentionally vague and kick the problem to TRANS and/or = CABForum. >=20 > 2) Limit the time to the time that CA issued a certificate to that = subject name >=20 >=20 > Part of the complexity here is that certificate issue on the = enterprise side is not typically authenticated by means that are within = PKIX or TRANS scope. >=20 Do others have an opinion? Russ --Apple-Mail=_4818E20A-A15C-4D13-A523-B444CA4E7708 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 29, 2017, at 11:16 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

On = Thu, Jun 29, 2017 at 11:05 AM, Russ Housley <housley@vigilsec.com> wrote:
Phill:

I just want to make sure I understand = your proposal.  I can see that a renew does not change the date in = the first-issued extension.  Does a rekey change it?

Russ

=E2=80=8BGood question!=E2=80=8B


=E2=80=8BThe simplest = implementation to audit would have the date be for the key and thus = change on rekey.

But the most useful = =E2=80=8Bimplementation would be to have the date correspond to the = subject and we certainly do not want to discourage rekeying.

That does leave open the question of whether = changes in the subject name cause a break and whether a CA may use the = earliest date at which any certificate was issued.


There is something of = a slippery slope here. I see two approaches

1)= Be intentionally vague and kick the problem to TRANS and/or = CABForum.

2)= Limit the time to the time that CA issued a certificate to that subject = name


Part of the complexity = here is that certificate issue on the enterprise side is not typically = authenticated by means that are within PKIX or TRANS scope.


Do others have = an opinion?

Russ

= --Apple-Mail=_4818E20A-A15C-4D13-A523-B444CA4E7708-- From nobody Thu Jun 29 08:30: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 0027413146F for ; Thu, 29 Jun 2017 08:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 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, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 IMrSezgrsZMC for ; Thu, 29 Jun 2017 08:30:01 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5551D13146B for ; Thu, 29 Jun 2017 08:30:01 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id E6FC6A007334 for ; Thu, 29 Jun 2017 08:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=3I5pNzebAYfg7Iir7O9/tn1+LfI=; b= OoCzmXObQWC/y24ek4mYPZAdEy1tnOl9nmf2w9hOreH5isxMxzUij2zW9eBD9z4p xiv3P9TtHShqdznIwGOAxhut84p347Lu3p50om2aJbDT9rgXDmbAwQPpKAKCYlha QyxSqIaUo9No2XVw0aT+Rcog5nDmO07chTZ0ykTLB3A= Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id B6BBFA007336 for ; Thu, 29 Jun 2017 08:30:00 -0700 (PDT) Received: by mail-wm0-f42.google.com with SMTP id w126so85760007wme.0 for ; Thu, 29 Jun 2017 08:30:00 -0700 (PDT) X-Gm-Message-State: AKS2vOyzWlpl3+Mw45QEH2CeW9oVEveeJj/iTDJFnvSCskO8sreF4WqE qZk8ZO+8HNC2CJbEcIlAjkBEWOZDYA== X-Received: by 10.28.225.133 with SMTP id y127mr11510562wmg.51.1498750198904; Thu, 29 Jun 2017 08:29:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.209 with HTTP; Thu, 29 Jun 2017 08:29:58 -0700 (PDT) In-Reply-To: References: From: Ryan Sleevi Date: Thu, 29 Jun 2017 11:29:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Phillip Hallam-Baker Cc: Russ Housley , LAMPS Content-Type: multipart/alternative; boundary="001a114b14023683ea05531af9bb" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 15:30:03 -0000 --001a114b14023683ea05531af9bb Content-Type: text/plain; charset="UTF-8" On Thu, Jun 29, 2017 at 10:51 AM, Phillip Hallam-Baker < phill@hallambaker.com> wrote: > I would like to suggest a new PKIX extension, the 'First Issued' > attribute. This has been discussed many times but not actually implemented > as far as I know. > Could you point to the past discussions, so that I can read up and hopefully otherwise avoid criticisms or concerns that may have already been raised or addressed in past discussions, but not covered in your brief description? --001a114b14023683ea05531af9bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 29, 2017 at 10:51 AM, Phillip Hallam-Baker <phill@hall= ambaker.com> wrote:
I would like to suggest a new PKIX= extension, the 'First Issued' attribute. This has been discussed m= any times but not actually implemented as far as I know.

Could you point to the past discussions, so t= hat I can read up and hopefully otherwise avoid criticisms or concerns that= may have already been raised or addressed in past discussions, but not cov= ered in your brief description?

--001a114b14023683ea05531af9bb-- From nobody Thu Jun 29 08:32: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 E297B12EC06 for ; Thu, 29 Jun 2017 08:31:59 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 kXWaWrbsPkfl for ; Thu, 29 Jun 2017 08:31:58 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 70BF5129B09 for ; Thu, 29 Jun 2017 08:31:58 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5TFQxIM024379 for ; Thu, 29 Jun 2017 16:31:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=qk0DuaDDmdYAL5cq1Ld4HySkgeGTcYraLKqfZXePQgQ=; b=fxzkyqAt3qOzcQChnLNMcxwND/h75dNPtjNOAFiN+nrsAeDGKVtqLVgBBh6Q5rRfiges V5wLFcA+x0v6Gjx0aY3X8ZBF1TZd8/z7oDTk6sxWkVRR2MYWoWuD0aVlk0ZBkWiLN1El aALa7HCdmcLzk/9PVy95f6yeXC31tJu/nnqn+XY4gVj00EkLZMDUa0aohVRzis5m4bYq A3FovhvRV+v8rLLeEgOrc6OBfwaFX6/Oxvwoa+QfmwsXqJ31ejicW9YFvoI6KyRtrjp0 sDRRyL5ix/qdD0keatzGSGCbNd9C29M4UaGuoIBnlssE7ysFw3Knn+nnudAAn0k8jWGr Lw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2bd3nyg8jf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 29 Jun 2017 16:31:55 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5TFR30X012210 for ; Thu, 29 Jun 2017 11:31:54 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b9kdv8jwk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 29 Jun 2017 11:31:54 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 29 Jun 2017 11:31:53 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 29 Jun 2017 11:31:53 -0400 From: "Salz, Rich" To: "spasm@ietf.org" Thread-Topic: [lamps] Recharter Discussion Thread-Index: AQHS7c+piGadg7oTPkeKQkzDVeF7q6I8Nc4AgAAD4ACAAAMegP//vnyAgAACmqA= Date: Thu, 29 Jun 2017 15:31:53 +0000 Message-ID: <4683482bb7c8469da9ff7eef4b6dc977@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-29_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706290252 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-29_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706290252 Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 15:32:00 -0000 SSB0aGluayB0aGlzIGlzIGFuIGludGVyZXN0aW5nIGV4dGVuc2lvbiBhbmQgY291bGQgYmUgdXNl ZnVsLg0KDQpJIHRoaW5rIGl0IHNob3VsZCBpbmRpY2F0ZSB0aGUgZmlyc3QgdGltZSB0aGF0IHRo ZSBrZXkgYW5kIHN1YmplY3ROYW1lIHdlcmUgY2VydGlmaWVkOyBpZiBlaXRoZXIgY2hhbmdlcywg dGhlIGRhdGUgZ2V0cyByZXNldC7CoCBUaGF0IHNlZW1zIHRoZSBzaW1wbGVzdCB0byB1bmRlcnN0 YW5kIGFuZCBleHBsYWluLCBldmVuIGlmIGl0IGxpbWl0cyB0aGUgdXRpbGl0eSBpbiBzb21lIGNv cm5lciBjYXNlcy4NCg0KLS3CoCANClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dp ZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbQ0KSU06IG1haWx0bzpyaWNoc2FsekBqYWJiZXIu YXQgVHdpdHRlcjogUmljaFNhbHoNCg== From nobody Thu Jun 29 08:34: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 54F7512EC06 for ; Thu, 29 Jun 2017 08:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a6t5ARY6sW2K for ; Thu, 29 Jun 2017 08:34:05 -0700 (PDT) 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 3C9B1131446 for ; Thu, 29 Jun 2017 08:34:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A6CCC300463 for ; Thu, 29 Jun 2017 11:34:04 -0400 (EDT) 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 qrNQA2IiIqys for ; Thu, 29 Jun 2017 11:34:03 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 98D2030023A for ; Thu, 29 Jun 2017 11:34:03 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: References: To: LAMPS Date: Thu, 29 Jun 2017 11:34:03 -0400 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] Fwd: [saag] Documenting the pretty Easy privacy (pEp) protocols X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 15:34:07 -0000 People on this list may find this message to the SAAG list interesting: = https://mailarchive.ietf.org/arch/msg/saag/2Kuhum0CIVNrb8_P-hVTLKgp388 I did not forward the message because any follow-up should take place on = the SAAG list. Russ From nobody Thu Jun 29 08:47:30 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 41D94129B09 for ; Thu, 29 Jun 2017 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 Ix0QXyakDLpS for ; Thu, 29 Jun 2017 08:47:26 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 EB1CC130133 for ; Thu, 29 Jun 2017 08:47:25 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id l13so55379806lfl.1 for ; Thu, 29 Jun 2017 08:47:25 -0700 (PDT) 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=ULYLHh4GznOCJI8p15JqFJWgHjQ7XviAv0Hd3+OLpok=; b=hfproYnz0AqG+//uMj2kCFVY4NVTVNMCG/qzCHyozt6TClDiYcKcUxYYEh6tsgV9zT uuXTJNotVBILQzt885IaYR3LqLXdUjXHmHuhZVVQ5ANexcQRZb35ZOpTe1Pgq/6S5m/q 0gxl6BL8Eri3oWLZ3gxdz8xYb2FftB5Y2caaGT4LaBl6zcy5bAANJwUtx/cRYbxrKHV0 snxE1F6N/UvfVlP/UzVTsYBx5PTi2C7vALMACeU8nX/3EwGvQR7ovfMwpi0wty1qwFd+ CHXYxczrZcCwWid8U4zdjHbrjKBYYa0jHTd5l17zhn0j/+Y9RbNUTI2tfOt/uJeRS/bc LMLQ== 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=ULYLHh4GznOCJI8p15JqFJWgHjQ7XviAv0Hd3+OLpok=; b=p7FGTXsenfXJB0VzszdWiGX472SftLY358w20kf0qFEJaeCypT5I7rAkQrln+Gdcyj fg6aRXTsf5iMbJUOWoOiv6DCqYpjz02YRL1D9H6k9CXA5MiKx179fFwc8p39VSr01seb Mr7YVHP0GJL3chW0z2oxP6xZGqQ0S+p1Y9kCjk79d/UvEskYX1I5o6Slx7wvNGJghF2Q N5lyamcuE5P1p7JjRYwBifdrx34XeHuVAmNbG8Tf/p1njnf2EC3sC3XEozGM+pKQjLy7 1+6PSzGkOk9KQyedB+RqxCOtfGpJ8E6Lm45gxH9PmCnXtmvXQoM+A4SX5dwQStNl/eGF hfKg== X-Gm-Message-State: AKS2vOwGWMOzsHsCcnjK8fSrABGowMFzTXfJr7durJLa0h3xBSN+n9lH cNM/+A7ZNLLblcVm6/8xwDRANU+cRA== X-Received: by 10.46.33.165 with SMTP id h37mr5573950lji.15.1498751244215; Thu, 29 Jun 2017 08:47:24 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Thu, 29 Jun 2017 08:47:23 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Thu, 29 Jun 2017 11:47:23 -0400 X-Google-Sender-Auth: O2Mp9vzcNXQaTlHW2nwAsxDtvRQ Message-ID: To: Ryan Sleevi Cc: Russ Housley , LAMPS Content-Type: multipart/alternative; boundary="001a1142bbc084aa7d05531b372c" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 15:47:29 -0000 --001a1142bbc084aa7d05531b372c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 29, 2017 at 11:29 AM, Ryan Sleevi wrote: > > > On Thu, Jun 29, 2017 at 10:51 AM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> I would like to suggest a new PKIX extension, the 'First Issued' >> attribute. This has been discussed many times but not actually implement= ed >> as far as I know. >> > > Could you point to the past discussions, so that I can read up and > hopefully otherwise avoid criticisms or concerns that may have already be= en > raised or addressed in past discussions, but not covered in your brief > description? > =E2=80=8BI will attempt to. I have to work out if it was presented or discu= ssed on the list and if presented whether I still have the powerpoints or if it was from my time at VRSN. There is also the question of where it was made. --001a1142bbc084aa7d05531b372c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--001a1142bbc084aa7d05531b372c-- From nobody Thu Jun 29 09:07: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 0093B131487 for ; Thu, 29 Jun 2017 09:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 Qwiu9gnIj60w for ; Thu, 29 Jun 2017 09:06:59 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 84BFA129B36 for ; Thu, 29 Jun 2017 09:06:55 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id h22so55625419lfk.3 for ; Thu, 29 Jun 2017 09:06:55 -0700 (PDT) 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=bsbtNYG0zo8dl4nxAdnCma3rr+83/12ZNa4Ku1CmDYo=; b=E3gO++bIY/5QtwK96+hMNcz6RfO0rIsDPQvZhuWvxNytC9DbK0I0oMWctn4p9/sxbd 0PHHHFrfvv0oWoMH7OrPdGG5T70becVDUKXIL8Mn+slGAbdvSOAqzthxWd6NQiuP2xVQ q6WL/70ZnI0Yljx7M6n9x9gmh425dYIDT9TqcEYBGpIWANu35ZICAnP6grM0BE6JQgx5 2zzlbhoaI2unXfKnE9oTy3YPGku6Xmpjd0dk5ACbgvX5bMiOVzdrO4geNLwnmkH4f/qh DNRSVV6/5Udz9dtK0BLlunoGcvSBMmk2Y2cJOyFsiNN+pIhDKpEihhGV264a4w292dld 5NWQ== 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=bsbtNYG0zo8dl4nxAdnCma3rr+83/12ZNa4Ku1CmDYo=; b=uUlpWqUrfNawk6psqH8FxPJGywq0G3tVYT1cJ+DW9CYeNfMjRnft/T4rMrHp6uD/Sg J6RIkWKlK4xqJhb5wGqod79g8pXAnfZuEhZ+lvaA23rjVgbkWMWD4Z5oN34jwX0DcaEi ADjv/0/BVMnE1Gzswexd6tgFF/RXG14F9ZKW7x+EZhMvfA7L9hRTiccs49+2vag6Zs2Q /JeM3t1UEUa6aVBvAqXy/kAfzgXWra1hBOszNy07RrgHFt6SjcVo1KTENgD4tBCDu2gt Y2bal+XEVLk0SIITsn6g6YjuGGnN3m/2WxSs3uwKCiELbgW/zVkTK+4xzBoXrAqMY3ii xFsA== X-Gm-Message-State: AKS2vOyEPwcjcvU51i/ZO/FVEIJyNHVQ1jARtuBnOL5NTz/PxERj/7kN V3NPmMVuiGw5LUtlwsnM2pUwHvA4Uw== X-Received: by 10.25.56.13 with SMTP id f13mr2929134lfa.167.1498752413471; Thu, 29 Jun 2017 09:06:53 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Thu, 29 Jun 2017 09:06:52 -0700 (PDT) From: Phillip Hallam-Baker Date: Thu, 29 Jun 2017 12:06:52 -0400 X-Google-Sender-Auth: Na8DgjEbt4qx-YnWnzFO8m8B15E Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="f403045ea344361b2a05531b7d2a" Archived-At: Subject: [lamps] Early discussion of First Issued/Member-Since X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 16:07:02 -0000 --f403045ea344361b2a05531b7d2a Content-Type: text/plain; charset="UTF-8" In response to Ryan's request. This is the first reference to it that is showing up on my mailing list searches. There did not seem to be any comment on that part of the proposal in that thread but it does provide a starting point for IPR Prior Art. I am not aware of any patent claims made by myself or any other party. My recollection is that this was not the first time I discussed it. The only objections I recall there were: 1) This is only needed if you do short lived certs and we are not doing that until we have an automated issue mechanism. 2) This would make CA services 'sticky' as changing CA would mean resetting the First Issued indication. My recollection was that the main reason for not going ahead was (1) which is now answered (as far as IETF is concerned) by ACME. We can address (2) while maintaining audit capability by allowing a CA to rely on an earlier CA's First Issued if the subject provides a satisfactory cryptographic proof they are the same party. E.g. by countersigning the CSR with an old key. This is one of those problems where it is a question of how many epicycles you wish to specify and whether you wish to leave some for future work. We have not discussed the structure of the extension. It could be merely a simple date or it could be a date plus an explanatory attribute stating the source of the first issued, whether this is the original key, a rekey, a subject change or a CA change. Or perhaps it is just a list of dates using the OPTIONAL feature of ASN.1 Adding support for short lived certs into TRANS is likely to be something of a performance in its own right when the time comes. While it is not necessary to provide any support at all, there is an obvious advantage to not cluttering up the logs or in splitting up the logs so that there are verbose and redacted versions. I see First Issued as potentially a piece of mechanism that might prove useful if we get to that problem rather than a reason to tackle it. ---------- Forwarded message ---------- From: Phillip Date: Mon, Mar 25, 2013 at 12:44 PM Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal To: public@cabforum.org Let us look at the situation in the most abstract terms possible. There are three types of information that might affect the client's decision to accept a certificate and present an assurance to the user (i.e. padlock or green bar): * The first date on which the subject was validated by the issuer (aka Member Since) * The most recent date on which the subject was validated by the issuer (aka Last validated) * The most recent date at which the issuer is known to have reported valid status (Last status) >From a security point of view it does not matter how the information is obtained, what matters is what information is available and how it is processed. Right now the issue date of the cert is identical to Last Validated which leads to the BR making particular assumptions. If that assumption is getting in the way of making the right decision to allow short lived certs as an alternative to OCSP then lets put that information into a certificate extension so that a client does not lose any information if we move to short lived certs. I would like to put Member Since and Last Validated in the cert if they are not the same as the issue date. Since we already allow for a delay in issue of status information it seems perfectly acceptable to assume that cert status is valid within a short time window of issue. If we look at what we have to do server side for OCSP stapling and what we have to do for short lived certs it is essentially the same. Short lived certs are simpler on the client side, only one trust chain to check. The client could even pre-fetch status for frequently used certs if that makes sense. There are issues to do with time. But note that even though we are obliged to allow for time to be out of sync on the client we can reasonably demand that CAs are correct to within an minute. The question is how the client should react when the status appears to be stale. There are serious issues there but they are exactly the same regardless of the status mechanism. We can't solve a time sync problem for short lived certs by pulling an OCSP token as that will appear to be stale or in the future as well. There are three questions for Last Status: * What status mechanisms do we want issuers to support? * What should the client do when it does not have valid status? * What should the BR allow? The last is not necessarily the same as first two. I think that we should not try to force the client into any particular approach to status other than a client should not be telling an end user a certificate is good if it does not have recent status. Turning on SSL is fine, a client should be able to turn on SSL any time that it would accept a raw TCP connection. But telling the user that they are safe with either the padlock or the green bar should not happen if the status is stale. _______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public --f403045ea344361b2a05531b7d2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In = response to Ryan's request.

This is the first reference to it that is showing up on my mailing l= ist searches. There did not seem to be any comment on that part of the prop= osal in that thread but it does provide a starting point for IPR Prior Art.=

I am not aware of any pa= tent claims made by myself or any other party.

My recollection is that this was not the first ti= me I discussed it. The only objections I recall there were:

1) This is only needed if you do short l= ived certs and we are not doing that until we have an automated issue mecha= nism.

2) This would make = CA services 'sticky' as changing CA would mean resetting the First = Issued indication.


My recollection = was that the main reason for not going ahead was (1) which is now answered = (as far as IETF is concerned) by ACME.=C2=A0

We can address (2) while maintaining audit capability = by allowing a CA to rely on an earlier CA's First Issued if the subject= provides a satisfactory cryptographic proof they are the same party. E.g. = by countersigning the CSR with an old key.

This is one of those problems where it is a question of h= ow many epicycles you wish to specify and whether you wish to leave some fo= r future work.
=
We have no= t discussed the structure of the extension. It could be merely a simple dat= e or it could be a date plus an explanatory attribute stating the source of= the first issued, whether this is the original key, a rekey, a subject cha= nge or a CA change. Or perhaps it is just a list of dates using the OPTIONA= L feature of ASN.1


Adding support f= or short lived certs into TRANS is likely to be something of a performance = in its own right when the time comes. While it is not necessary to provide = any support at all, there is an obvious advantage to not cluttering up the = logs or in splitting up the logs so that there are verbose and redacted ver= sions.

I see First Issued= as potentially a piece of mechanism that might prove useful if we get to t= hat problem rather than a reason to tackle it.


---------- Forwa= rded message ----------
From: Phillip = <philliph@comod= o.com>
Date: Mon, Mar 25, 2013 at 12:44 PM
Subject: Re:= [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal
To: public@cabforum.org


Let us= look at the situation in the most abstract terms possible. There are three= types of information that might affect the client's decision to accept= a certificate and present an assurance to the user (i.e. padlock or green = bar):

* The first date on which the subject was validated by the issuer (aka Memb= er Since)
* The most recent date on which the subject was validated by the issuer (ak= a Last validated)
* The most recent date at which the issuer is known to have reported valid = status (Last status)

>From a security point of view it does not matter how the information is= obtained, what matters is what information is available and how it is proc= essed. Right now the issue date of the cert is identical to Last Validated = which leads to the BR making particular assumptions. If that assumption is = getting in the way of making the right decision to allow short lived certs = as an alternative to OCSP then lets put that information into a certificate= extension so that a client does not lose any information if we move to sho= rt lived certs. I would like to put Member Since and Last Validated in the = cert if they are not the same as the issue date.

Since we already allow for a delay in issue of status information it seems = perfectly acceptable to assume that cert status is valid within a short tim= e window of issue. If we look at what we have to do server side for OCSP st= apling and what we have to do for short lived certs it is essentially the s= ame. Short lived certs are simpler on the client side, only one trust chain= to check. The client could even pre-fetch status for frequently used certs= if that makes sense.

There are issues to do with time. But note that even though we are obliged = to allow for time to be out of sync on the client we can reasonably demand = that CAs are correct to within an minute. The question is how the client sh= ould react when the status appears to be stale. There are serious issues th= ere but they are exactly the same regardless of the status mechanism. We ca= n't solve a time sync problem for short lived certs by pulling an OCSP = token as that will appear to be stale or in the future as well.

There are three questions for Last Status:

* What status mechanisms do we want issuers to support?
* What should the client do when it does not have valid status?
* What should the BR allow?

The last is not necessarily the same as first two. I think that we should n= ot try to force the client into any particular approach to status other tha= n a client should not be telling an end user a certificate is good if it do= es not have recent status. Turning on SSL is fine, a client should be able = to turn on SSL any time that it would accept a raw TCP connection. But tell= ing the user that they are safe with either the padlock or the green bar sh= ould not happen if the status is stale.



_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

--f403045ea344361b2a05531b7d2a-- From nobody Thu Jun 29 09:17:13 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 21E70129B36 for ; Thu, 29 Jun 2017 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 RIVcwH_095ox for ; Thu, 29 Jun 2017 09:17:10 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 E1191129B33 for ; Thu, 29 Jun 2017 09:17:09 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id 70so855358wmo.1 for ; Thu, 29 Jun 2017 09:17:09 -0700 (PDT) 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=XtDFeBaduCTF+uQzGn8o35BOi1jYAvB1KzGBHVsnj0c=; b=A+wb5X5bOTiU8yT6kcpt2eJgz/RW6uHk3uqGYbX8k5GIpxIrCJcOQfi8dWx8wbcS94 UDFN2YtROmXQMc6yy2Sjv86FWP5S0Y7M5OUiJyGMG5TL39255JR73TP2/bIX16Hzd6CV a8IcN5gL/dAdIR9Gyuc7C2IRZCAPqO5RmR2frjuHVxZBGPtgXxNR6ZIfI6MMD4YCZ6u5 MAHE2gpgZSlp9CmuEH8/yzqR9+kK5J8XJeEBBQHkGYnqYvtNC0OBi4wJ5PBKr3OFoKPm A7fk54qV/c0Apm7f5zqoiNTnijtr+Hr1hNyp+UHj5lAbIeecR+9a3w/e3fZoFLnhHz4G OVZQ== 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=XtDFeBaduCTF+uQzGn8o35BOi1jYAvB1KzGBHVsnj0c=; b=J+NaEUdh+bxeNTS0cKsysk/sXa3bgM7G0qpcC0QXYKkryBy2bc1Rk2OS7hxdWTr1e+ 6lRpvKf/1T7k8jalLll0YoKo4PQoik7uRVsM1iiqXtHtI01G6W3ctyUenh90vBnKID2/ 7pxb5qX8nR607YmHs5l2K4R6wBzhLPydWFNTyiwkYMSkHeDVqD7dZ8khQKDyzv2fD+bN EAlwOfbarJODvXTV3GA0rYH+NhJuSeNaGvqhNJunrBsYp53PNOBV7gGBT/C6KP2bFokt zksGvBnZaqUOgkByCEaio67qlOVotzj5ejjqofgwt837RFBBxFNmXAL00R3X1dCwzYzq adZA== X-Gm-Message-State: AKS2vOze+//c3Qs3qJrt2i9oTY/a5Uip+4XhGTFA6vKpXK0mahXcpqRW c31az38r/NDn14Zs9EE= X-Received: by 10.80.204.214 with SMTP id b22mr2243369edj.16.1498753028447; Thu, 29 Jun 2017 09:17:08 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k49sm1548758eda.45.2017.06.29.09.17.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 09:17:07 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E36B5EEC-B755-4A83-98A6-4FF4C788C6AD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 19:17:05 +0300 In-Reply-To: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> Cc: Phillip Hallam-Baker , LAMPS To: Russ Housley References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 16:17:12 -0000 --Apple-Mail=_E36B5EEC-B755-4A83-98A6-4FF4C788C6AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Jun 2017, at 18:21, Russ Housley wrote: >=20 >>=20 >> On Jun 29, 2017, at 11:16 AM, Phillip Hallam-Baker = > wrote: >>=20 >> On Thu, Jun 29, 2017 at 11:05 AM, Russ Housley > wrote: >> Phill: >>=20 >> I just want to make sure I understand your proposal. I can see that = a renew does not change the date in the first-issued extension. Does a = rekey change it? >>=20 >> Russ >>=20 >> =E2=80=8BGood question!=E2=80=8B >>=20 >>=20 >> =E2=80=8BThe simplest implementation to audit would have the date be = for the key and thus change on rekey. >>=20 >> But the most useful =E2=80=8Bimplementation would be to have the date = correspond to the subject and we certainly do not want to discourage = rekeying. >>=20 >> That does leave open the question of whether changes in the subject = name cause a break and whether a CA may use the earliest date at which = any certificate was issued. >>=20 >>=20 >> There is something of a slippery slope here. I see two approaches >>=20 >> 1) Be intentionally vague and kick the problem to TRANS and/or = CABForum. >>=20 >> 2) Limit the time to the time that CA issued a certificate to that = subject name >>=20 >>=20 >> Part of the complexity here is that certificate issue on the = enterprise side is not typically authenticated by means that are within = PKIX or TRANS scope. >>=20 >=20 > Do others have an opinion? It kind of reminds me of this (3rd slide): https://www.ietf.org/proceedings/69/slides/pkix-5.pdf = As I understood it at the time, it was meant to be a stand-in for = reputation, and that role was taken over by EV. I agree that it has value for DV certificates, especially short-term = ones. But it makes switching certificate issuers hard. Every time your = domain switches to a new issuer, you lose the reputation value of this = extension. I see this as a problem unless CABForum intends to make all its members = share databases. Yoav --Apple-Mail=_E36B5EEC-B755-4A83-98A6-4FF4C788C6AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 29 Jun 2017, at 18:21, Russ Housley <housley@vigilsec.com> wrote:


On Jun 29, 2017, at 11:16 AM, = Phillip Hallam-Baker <phill@hallambaker.com> wrote:

On = Thu, Jun 29, 2017 at 11:05 AM, Russ Housley <housley@vigilsec.com> wrote:
Phill:

I just want to make sure I understand = your proposal.  I can see that a renew does not change the date in = the first-issued extension.  Does a rekey change it?

Russ

=E2=80=8BGood question!=E2=80=8B


=E2=80=8BThe = simplest implementation to audit would have the date be for the key and = thus change on rekey.

But the most useful = =E2=80=8Bimplementation would be to have the date correspond to the = subject and we certainly do not want to discourage rekeying.

That does leave open the question of whether changes in the = subject name cause a break and whether a CA may use the earliest date at = which any certificate was issued.


There is something of a slippery slope here. I see two = approaches

1) Be intentionally vague and kick the = problem to TRANS and/or CABForum.

2) Limit the time to = the time that CA issued a certificate to that subject name


Part of the complexity here is that = certificate issue on the enterprise side is not typically authenticated = by means that are within PKIX or TRANS scope.


Do others have an opinion?

It kind of reminds me of this (3rd slide):
https://www.ietf.org/proceedings/69/slides/pkix-5.pdf
=

As I understood it = at the time, it was meant to be a stand-in for reputation, and that role = was taken over by EV.

I agree that it has value for DV certificates, especially = short-term ones. But it makes switching certificate issuers hard. Every = time your domain switches to a new issuer, you lose the reputation value = of this extension.

I see this as a problem unless CABForum intends to make all = its members share databases.

Yoav

= --Apple-Mail=_E36B5EEC-B755-4A83-98A6-4FF4C788C6AD-- From nobody Thu Jun 29 09:37: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 40D26129B77 for ; Thu, 29 Jun 2017 09:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 DbZQ9IyJlu0w for ; Thu, 29 Jun 2017 09:37:56 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 D69FA124E15 for ; Thu, 29 Jun 2017 09:37:55 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id l13so56191539lfl.1 for ; Thu, 29 Jun 2017 09:37:55 -0700 (PDT) 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=nQwz5lK2dXn6idlwAYcUD3u473/K40ACaDzBxFvStws=; b=MyLloEI6B4fGLGsPUx3J9cCXhB315HBROFwJd5I/w+gwc/pPGA2eHBZmGybQW87icp yT+2PdFY1XD+yQdRgOqrNC0ehJgmkPCY92myzk0J5QhteErRD06xOk2s3XYZd8to9TFo vCdKyC60AFe8aI1+9+uW/ywFlIDpojAg4Cl8yjnLN/ZE7WiD5QBcBlUFsruXbGLI5ivn V/MLW2mD49qgHTfxckdPACEKbjOq9sfxnczJnC1qMrq4bXOV+h43QIVl0xERQ0+H5RKz e88K7D7FYyRTd+Bj3YCTdiQ/buc5pUT0BUXTZPGfQw1GEUSGlzkbeAxaLlmAPLQmghgz XJjA== 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=nQwz5lK2dXn6idlwAYcUD3u473/K40ACaDzBxFvStws=; b=N4lX7BiOUEIUBzj8t+VjTNvkUKbne2T9F31Yr65BZhMx4Xi1T7312lHA2RrjAaqTLx gI7MBe3NhelteKdq5vXOFO7lX1SfxAkMsEwqNq1y/IjEBeuO8edMIE8IqHUJO8RfNm3E S3mrjdqRy4etXD4ePC4BTmxlERRPxX6vjUhG4RurIkd+9VNpPjbYFTJqm34kVVvYb7KZ ZMu8VAra/uw2KwiB+5iQEVBUiezFFIVZ0GWXXzGTUpkmFxizJnF3Wa9TYg8+PhxCei/q T1Kjkyn6/vosTB5PSIce9DtYEbCaCYT89ZgbsUGEf2sfUPiwttOahVNRL43adI8YQ+BH FVUQ== X-Gm-Message-State: AKS2vOxQGvbF3jOEhTRZZDY7a7iYXLp/w1/S9l2cpz/X3b9CW7L5sDFE hsnQwjrzJc8xe0KGYeodHcNTORtnAA== X-Received: by 10.25.56.13 with SMTP id f13mr2968111lfa.167.1498754274100; Thu, 29 Jun 2017 09:37:54 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Thu, 29 Jun 2017 09:37:52 -0700 (PDT) In-Reply-To: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> From: Phillip Hallam-Baker Date: Thu, 29 Jun 2017 12:37:52 -0400 X-Google-Sender-Auth: Z4GcWiAJTKEWJ2vc4HM-4Vfq3tA Message-ID: To: Yoav Nir Cc: Russ Housley , LAMPS Content-Type: multipart/alternative; boundary="f403045ea3441d0cb005531bec37" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 16:37:58 -0000 --f403045ea3441d0cb005531bec37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I remembered making the proposal but not when. EV was well underway at that time. This was not intended to be an alternative, it was more of an enhancement. The third proposal, suppressing the UI entirely for device certs is something I think we should return to but for different reasons. The aim then was to enable free certs with what I now call 'minimal validation' without diluting the value of DV. On Thu, Jun 29, 2017 at 12:17 PM, Yoav Nir wrote: > > On 29 Jun 2017, at 18:21, Russ Housley wrote: > > > On Jun 29, 2017, at 11:16 AM, Phillip Hallam-Baker > wrote: > > On Thu, Jun 29, 2017 at 11:05 AM, Russ Housley > wrote: > >> Phill: >> >> I just want to make sure I understand your proposal. I can see that a >> renew does not change the date in the first-issued extension. Does a re= key >> change it? >> >> Russ >> > > =E2=80=8BGood question!=E2=80=8B > > > =E2=80=8BThe simplest implementation to audit would have the date be for = the key > and thus change on rekey. > > But the most useful =E2=80=8Bimplementation would be to have the date cor= respond > to the subject and we certainly do not want to discourage rekeying. > > That does leave open the question of whether changes in the subject name > cause a break and whether a CA may use the earliest date at which any > certificate was issued. > > > There is something of a slippery slope here. I see two approaches > > 1) Be intentionally vague and kick the problem to TRANS and/or CABForum. > > 2) Limit the time to the time that CA issued a certificate to that subjec= t > name > > > Part of the complexity here is that certificate issue on the enterprise > side is not typically authenticated by means that are within PKIX or TRAN= S > scope. > > > Do others have an opinion? > > > It kind of reminds me of this (3rd slide): > https://www.ietf.org/proceedings/69/slides/pkix-5.pdf > > As I understood it at the time, it was meant to be a stand-in for > reputation, and that role was taken over by EV. > > I agree that it has value for DV certificates, especially short-term ones= . > But it makes switching certificate issuers hard. Every time your domain > switches to a new issuer, you lose the reputation value of this extension= . > > I see this as a problem unless CABForum intends to make all its members > share databases. > > Yoav > > --f403045ea3441d0cb005531bec37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tha= nks, I remembered making the proposal but not when.

EV was well underway at that time. This was not = intended to be an alternative, it was more of an enhancement.


The third proposal, suppressing the UI entirely = for device certs is something I think we should return to but for different= reasons. The aim then was to enable free certs with what I now call 'm= inimal validation' without diluting the value of DV.





On Thu, Jun 29, 2017 at 12:17 PM, Yoav Nir <= ;ynir.ietf@gmail.c= om> wrote:

On 29 Jun 2017, at 18:21, Russ Housley <housley@vigilsec.com> wrote:


On Jun 29, 2017, at 11:16 AM, Phillip Hallam-Baker <phill@hallambaker.com> wr= ote:

O= n Thu, Jun 29, 2017 at 11:05 AM, Russ Housley=C2=A0<housley@vigilsec.com>= ;= =C2=A0wrote:
Phill:
I just want to make sure I understand your proposal.=C2=A0 I ca= n see that a renew does not change the date in the first-issued extension.= =C2=A0 Does a rekey change it?

Russ
<= /div>

=E2=80=8BGood question!=E2=80=8B


=
=E2=80=8B= The simplest implementation to audit would have the date be for the key and= thus change on rekey.

Bu= t the most useful =E2=80=8Bimplementation would be to have the date corresp= ond to the subject and we certainly do not want to discourage rekeying.

That does leave open the que= stion of whether changes in the subject name cause a break and whether a CA= may use the earliest date at which any certificate was issued.


There is something of a slippery slope here. I= see two approaches

1) Be= intentionally vague and kick the problem to TRANS and/or CABForum.

2) Limit the time to the time = that CA issued a certificate to that subject name


Part of the complexity here is that certificate issue on the= enterprise side is not typically authenticated by means that are within PK= IX or TRANS scope.


Do others have an opinion?

It kind of reminds me of this (3rd slide):

<= div>As I understood it at the time, it was meant to be a stand-in for reput= ation, and that role was taken over by EV.

I agree= that it has value for DV certificates, especially short-term ones. But it = makes switching certificate issuers hard. Every time your domain switches t= o a new issuer, you lose the reputation value of this extension.
=
I see this as a problem unless CABForum intends to make all = its members share databases.

Yoav


--f403045ea3441d0cb005531bec37-- From nobody Thu Jun 29 09:47:54 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 EEEA012EC5E for ; Thu, 29 Jun 2017 09:47:52 -0700 (PDT) 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 fcGBd1W-WCJo for ; Thu, 29 Jun 2017 09:47:50 -0700 (PDT) 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 AE3D512EC44 for ; Thu, 29 Jun 2017 09:47:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 54CFCBE4D; Thu, 29 Jun 2017 17:47:48 +0100 (IST) 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 32omNCiaL2cQ; Thu, 29 Jun 2017 17:47:47 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DD599BE4C; Thu, 29 Jun 2017 17:47:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498754867; bh=76zZ2c9rAZ3ALxG9VFUM8gWjFdwsoJ3sfq/6jQW5vF4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aUhW/WxBljGEc/hOVSvUQBqNY0rC5iKRgbcRP+RH/Rw7ZEOdG0RR0uFvjp1Y59zpi d/Zzk4w9fXhRiArcGCnhmV8oGItXOtoGU6B5Tm9tQxcfTDg6MDjMksPvOSuucCJiff TRxmU/s1mjSBouMnCYV3pt48DkDumC0gZBShbq1o= To: Russ Housley , Phillip Hallam-Baker Cc: LAMPS References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 29 Jun 2017 17:47:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6KEhjau5IdgC6cWSicbEQMjXc018QTmT" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 16:47:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d6KEhjau5IdgC6cWSicbEQMjXc018QTmT Content-Type: multipart/mixed; boundary="NkE9PwAsRt4AMTHhcihXa6vXqFTnDkBbh"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , Phillip Hallam-Baker Cc: LAMPS Message-ID: Subject: Re: [lamps] Recharter Discussion References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> In-Reply-To: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> --NkE9PwAsRt4AMTHhcihXa6vXqFTnDkBbh Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 29/06/17 16:21, Russ Housley wrote: > Do others have an opinion? The function sounds useful but perhaps better provided via an API to a CT log (not sure). The reason I'd wonder about that is that it's hard to see what code would read this new value and not want more information than that. A CT log API could provide more so might be more useful (e.g. if an RP could ask "show me your history of meta-data related to certs for example.com"). Probably not that relevant, but similar information would also exist in passive DNS DBs I guess. S. --NkE9PwAsRt4AMTHhcihXa6vXqFTnDkBbh-- --d6KEhjau5IdgC6cWSicbEQMjXc018QTmT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZVS8yAAoJEC88hzaAX42iwAEH/3g96IGAPa0Xl6BXtY7qAoCY HDP+7eZxtg9gIg0vtVYjLyX6hZyK5PKYvLYePbPi9BdfpBHhBhP2HHd3Q/4uiZ/B 8t765bIjxbNm7EcIcl1FCvytzqHnrSBeHxctPINrUcckjEeYces/wcapEqCwGYLl pGWVQlfQ4S27YK2gCv1Fmuad6WDFl/AGd5AGkvPnOc4K5Uh+fdA6wr0Evf257yGM weuCLXpuxheSoQ1vUNjCRddzAiWWgs1ii2A/EqmwpRkHn9mplfzz5Kz6R2+N+C01 CRByP5GccasloKAZJs7VN8W/pXqjkSLPyD0tqhTnmeX+C/wZedtI3k7hvZ5Ojbc= =NcMn -----END PGP SIGNATURE----- --d6KEhjau5IdgC6cWSicbEQMjXc018QTmT-- From nobody Thu Jun 29 09:54: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 D997712EAC1 for ; Thu, 29 Jun 2017 09:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 PocVElqdxC_a for ; Thu, 29 Jun 2017 09:54:20 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 2A3E4129B41 for ; Thu, 29 Jun 2017 09:54:20 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id l13so56438003lfl.1 for ; Thu, 29 Jun 2017 09:54:20 -0700 (PDT) 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=6DMfj2QTW7ROspv/HjKJmIEglSvYRxgtEtp8eh+wj4A=; b=DlgEwIdbSx3BwJDq6/VyYnJcXvb320V2AajOhcwSugBHw0+w3oIz1W9dh1FTiTD8O/ JSlgcWowevU/ASlYTVbCktKhuVGcelrlS89vIsAtaZ02S/bC8tx9Dx2xgVvs23zPF/xk ueexK6+grEMYQMVbc6sPx56U6NnInnZ+Ae8gcUtbTpuhZDtS1EtSfHAjfPuOCkSRp3TE GX6hAQqBiQdx/aCC5CehppIO75yY2NlEOW5WGGZkWCwsinlde6KVr4w4FWB9tnViVop6 JnsKfu60eyBn5k3w9f6WMqwrNdlN+8aEUlNc4Opdrium2RZoUYp7MwofEuWMNd8o619q YThg== 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=6DMfj2QTW7ROspv/HjKJmIEglSvYRxgtEtp8eh+wj4A=; b=boTih3FBzvMPuS8KrQHVRaBhsieCmYIqPx1B3C2DKUWaXm/F1/BLg5oTTanz0SZ7WV uouF5Lj52pZwt0IgxHRT0AXdWCecusb29PrJeOhzJPfUTcxy487zBYy0Ku8SwdEvs0Ai 384/RvO6CvFaZjpN3ku2r1fvHMfeeUh6MQRdkq5jnprJQ2GH53bH5xFdPgapP0n5IVZz g2dd42jTEPNZQkvI98zkJ7vNiQkl0yuldymXZXwSxV/WkKLcPF4IoVp/vu1XXdxDhG8v rL+TxxF09NI6gS086N/C9609vhereMjtHaPf85Mbau8Yld2rqJvwX2lg56mIsBHSgCcO aXEQ== X-Gm-Message-State: AKS2vOznBioM0GS7cp5L0pA9D4sGa3ctLCecPZTJtdaJu9/7xOMi1H08 KQVo2b7o23hN1Dy6RDXb3Cc/1LTWOw== X-Received: by 10.46.33.165 with SMTP id h37mr5671499lji.15.1498755258450; Thu, 29 Jun 2017 09:54:18 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Thu, 29 Jun 2017 09:54:17 -0700 (PDT) In-Reply-To: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> From: Phillip Hallam-Baker Date: Thu, 29 Jun 2017 12:54:17 -0400 X-Google-Sender-Auth: 9ngFfCCzx-gr1yx_-BUVpgpUrOg Message-ID: To: Stephen Farrell Cc: Russ Housley , LAMPS Content-Type: multipart/alternative; boundary="001a1142bbc0c908d505531c26ea" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jun 2017 16:54:23 -0000 --001a1142bbc0c908d505531c26ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell wrote: > > > On 29/06/17 16:21, Russ Housley wrote: > > Do others have an opinion? > > The function sounds useful but perhaps better provided > via an API to a CT log (not sure). The reason I'd wonder > about that is that it's hard to see what code would > read this new value and not want more information than > that. A CT log API could provide more so might be more > useful (e.g. if an RP could ask "show me your history of > meta-data related to certs for example.com"). > > Probably not that relevant, but similar information would > also exist in passive DNS DBs I guess. > =E2=80=8BThere is always a cut off between the standardized parts and the r= est. When I first proposed this, it was for human consumption. What I am thinking about now is rather more of a hook for likely proprietary AI systems reading it.=E2=80=8B =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now we ca= n eliminate what? 95% of phishing sites with free DV certs by simply rejecting any certs less than 5 days old. =E2=80=8B =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be important. B= ut not something we are going to be able to really work on at all, let alone standardize until after we have data. All I want to do right now is to instrument so we can start collecting data= . --001a1142bbc0c908d505531c26ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <stephen.farrell@cs= .tcd.ie> wrote:


On 29/06/17 16:21, Russ Housley wrote:
> Do others have an opinion?

The function sounds useful but perhaps better provided
via an API to a CT log (not sure). The reason I'd wonder
about that is that it's hard to see what code would
read this new value and not want more information than
that. A CT log API could provide more so might be more
useful (e.g. if an RP could ask "show me your history of
meta-data related to certs for example.com").

Probably not that relevant, but similar information would
also exist in passive DNS DBs I guess.

=
=E2=80=8BThere is al= ways a cut off between the standardized parts and the rest.

When I first proposed this, it was for h= uman consumption. What I am thinking about now is rather more of a hook for= likely proprietary AI systems reading it.=E2=80=8B

=E2=80=8BSecurity is ri= sk mitigation, not risk elimination. Right now we can eliminate what? 95% o= f phishing sites with free DV certs by simply rejecting any certs less than= 5 days old. =E2=80=8B


=E2=80=8BWhat we do next with the =E2= =80=8Bdata is going to be important. But not something we are going to be a= ble to really work on at all, let alone standardize until after we have dat= a.

All I want to do right= now is to instrument so we can start collecting data.

=
--001a1142bbc0c908d505531c26ea-- From nobody Fri Jun 30 07:04:56 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 00048129AE5 for ; Fri, 30 Jun 2017 07:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=-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=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 vt_cIPgd2g9t for ; Fri, 30 Jun 2017 07:04:52 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 3E82D1242F5 for ; Fri, 30 Jun 2017 07:04:52 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id k192so24969313ith.1 for ; Fri, 30 Jun 2017 07:04:52 -0700 (PDT) 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 :cc; bh=YKegNqoqAN+/akzmJe+ZmxQC55VyyxW6B8zSo3XdKUE=; b=WD3SnhvrzQD67ksMpBKaEMevhbOtM/quLJY++Gk/YzoOwau0bMA9EqOwBAFX7JmG+D rkPS7KpoiybSY0ek7vJkPr0thIUlAqxSt1B+6e25X/xYs7hBQzuhTlpsI0ae1xgyi6ym T8C/E49PV+qSDcBWTA5lJGF1vclWdpX3YCNr9YCWVsybiHFquH0ZV5xVNtZg4V41Dsyb DfNQ/5mJThJaUgfex9qCBgWd5PgstG2SbwcPaJ8SPwnBimgv1k7Ijgspi0uf1Xk+IFFx u8t8oV1suNUizJK7LJqtooLsZ4IO7UXEIFTbg0mlGIPjwAxnREsQNiWzpPfDSWjap97G v9Jw== 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=YKegNqoqAN+/akzmJe+ZmxQC55VyyxW6B8zSo3XdKUE=; b=rhiiDzKhMKdDBd4A5tMgWikDBzbfWjThh3oOjluCwHYoWVIkJ+6TFIiG2zz/VrvCvz ixw5UwLdFkBfNSzeXoZev7PIcos030KPkTbp45X/ErNBBTcNET5GpkgoD7OpQmBqp43E H7uQXK8MnvLPC3pL+rtEbou528zEjYtjs77na6DRw56r9OvSvGmgHij7IJ4FXNBZ/ysE XWq/5Y9KO2XrptmzqzV9E4s2WDZzZBwDISmIDl6/V5I19W5/ANzOY4KF7b87LWEHkWIe 7uOap6EAklB1Ss2zb/GewkQwelGAZQuKbPSGwQd85rG2h8YduZe7QUgVS4PYeMoJiyoY CGPw== X-Gm-Message-State: AKS2vOzUsj4HJr1TvD6jMWQOxGmcRJtKL9pg0QqYd8zoDhBH8achNJHF u6y3Jt7nB4taSUBYGKemFWT8P44R557TA3Y= X-Received: by 10.36.217.207 with SMTP id p198mr19969859itg.116.1498831490829; Fri, 30 Jun 2017 07:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.77 with HTTP; Fri, 30 Jun 2017 07:04:50 -0700 (PDT) In-Reply-To: <7D6AC11A-1F96-4072-B163-E7DFC4EA1A94@vigilsec.com> References: <149790190464.10769.10138265629051334555.idtracker@ietfa.amsl.com> <7D6AC11A-1F96-4072-B163-E7DFC4EA1A94@vigilsec.com> From: Wei Chuang Date: Fri, 30 Jun 2017 07:04:50 -0700 Message-ID: To: Russ Housley Cc: Alexey Melnikov , LAMPS Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113718b2a4866205532de641" Archived-At: Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-eai-addresses-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 14:04:55 -0000 --001a113718b2a4866205532de641 Content-Type: multipart/alternative; boundary="001a113718b297547b05532de6a6" --001a113718b297547b05532de6a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 22, 2017 at 6:39 AM, Russ Housley wrote: > I have a few minor comments on this document. > > > Section 5 says: > > ... (section 7.5 and 7.2 in [RFC5280]) ... > > These sections are updated by draft-ietf-lamps-rfc5280-i18n-update-01. > It would help the reader to point to this document as well. Maybe: > > ... (sections 7.2 and 7.5 in [RFC5280] as updated by > [ID-lamps-rfc5280-i18n-update]) ... > > Done. > > Section 6 says: > > =E2=80=A6 this specification modifies and > extends rfc822Name name SmtpUTF8Name does not violate existing name > constraints. > > I cannot figure out what this sentence is trying to say. Please reword. > Clarified by expanding the text. > > > Section 6 has text to forbid constraints on the local-part of email > addresses. > This update to RFC 5280 is already included in > draft-ietf-lamps-rfc5280-i18n-update-01. > I do not think that it needs to be in both documents. I suggest that thi= s > document > point to the change. > References that draft. > > > In Section 8: > s/in Section Section 3/In Section 3/ > s/Section Appendix A./Appendix A./ > Done. > > > In Appendix A, please remove "Figure 2=E2=80=9D from the end of the ASN.1= module. > > Done. > > I hope these few comments can be addressed in the next few days. They ar= e > all simple. > > Russ > -Wei > > > > > On Jun 19, 2017, at 3:51 PM, internet-drafts@ietf.org wrote: > > > > > > A new version of I-D, draft-ietf-lamps-eai-addresses-11.txt > > has been successfully submitted by Weihaw Chuang and posted to the > > IETF repository. > > > > Name: draft-ietf-lamps-eai-addresses > > Revision: 11 > > Title: Internationalized Email Addresses in X.509 > certificates > > Document date: 2017-06-18 > > Group: lamps > > Pages: 11 > > URL: https://www.ietf.org/internet- > drafts/draft-ietf-lamps-eai-addresses-11.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai- > addresses/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-lamps-eai- > addresses-11 > > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-ietf-lamps-eai-addresses-11 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-ea= i- > addresses-11 > > > > Abstract: > > This document defines a new name form for inclusion in the otherName > > field of an X.509 Subject Alternative Name and Issuer Alternative > > Name extension that allows a certificate subject to be associated > > with an Internationalized Email Address. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > --001a113718b297547b05532de6a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 22, 2017 at 6:39 AM, Russ Housley <housley@vigilsec.com= > wrote:
I have a few minor= comments on this document.


Section 5 says:

=C2=A0 =C2=A0... (section 7.5 and 7.2 in [RFC5280]) ...

These sections are updated by draft-ietf-lamps-rfc5280-i18n-update-01.=
It would help the reader to point to this document as well.=C2=A0 Maybe:
=C2=A0 =C2=A0... (sections 7.2 and 7.5 in [RFC5280] as updated by [ID-lamps= -rfc5280-i18n-update]) ...


Done.
=C2=A0

Section 6 says:

=C2=A0 =C2=A0=E2=80=A6 this specification modifies and
=C2=A0 =C2=A0extends rfc822Name name SmtpUTF8Name does not violate existing= name
=C2=A0 =C2=A0constraints.

I cannot figure out what this sentence is trying to say.=C2=A0 Please rewor= d.

Clarified by expanding the text.
=C2=A0


Section 6 has text to forbid constraints on the local-part of email address= es.
This update to RFC 5280 is already included in draft-ietf-lamps-rfc5280-i18= n-update-01.
I do not think that it needs to be in both documents.=C2=A0 I suggest that = this document
point to the change.

References that dr= aft.
=C2=A0


In Section 8:
=C2=A0 s/in Section Section 3/In Section 3/
=C2=A0 s/Section Appendix A./Appendix A./

Done.
=C2=A0


In Appendix A, please remove "Figure 2=E2=80=9D from the end of the AS= N.1 module.


Done.
=C2=A0

I hope these few comments can be addressed in the next few days.=C2=A0 They= are all simple.

Russ

-Wei
=C2= =A0



> On Jun 19, 2017, at 3:51 PM, internet-drafts@ietf.org wrote:
>
>
> A new version of I-D, draft-ietf-lamps-eai-addresses-11.txt
> has been successfully submitted by Weihaw Chuang and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-lamps-eai-addresses<= br> > Revision:=C2=A0 =C2=A0 =C2=A011
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Internat= ionalized Email Addresses in X.509 certificates
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-18
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lamps > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ie= tf-lamps-eai-addresses-11.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-11
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai= -addresses-11
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lam= ps-eai-addresses-11
>
> Abstract:
>=C2=A0 =C2=A0This document defines a new name form for inclusion in the= otherName
>=C2=A0 =C2=A0field of an X.509 Subject Alternative Name and Issuer Alte= rnative
>=C2=A0 =C2=A0Name extension that allows a certificate subject to be ass= ociated
>=C2=A0 =C2=A0with an Internationalized Email Address.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>


--001a113718b297547b05532de6a6-- --001a113718b2a4866205532de641 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD8H4oGeFVJh4Yyeh3XPoiC RI6G8kB6LeKViBqzffG0hTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA2MzAxNDA0NTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAY+zS+ZC7QpQC7UyCX+/rjHxghqKnGvGL8fWSLL5o FFetZAqGyuelAhsPU6LmveRLVOjFKbUudvRqDYdP+dRKv1I3En9Z+iTCaXl+a3C6lArh4/DHegIN xIL16OQiHWUltRDEGghLr+h9pz/u3rAb+pNgOQz7cNDCK3GOAjN5qyeB/Pohq2edc9jU/yt6CU6U jtkljOlW5t790UHEW2OTkgqe0N+Wy6DuUJqTIw5b4v06/3x032MDhCj5XE4MuiHIf6B++vQVXRUI FlsGu9DHl3CCR/G4Va9ZxxEmRYVTx9bC95i3L8jhF0b6irj0J+aJFZ5ipa7fzCMmMC9aNqTkZQ== --001a113718b2a4866205532de641-- From nobody Fri Jun 30 07:05:20 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 951461242F5; Fri, 30 Jun 2017 07:05:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149883150556.4606.15593836051908357282@ietfa.amsl.com> Date: Fri, 30 Jun 2017 07:05:05 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-eai-addresses-12.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 14:05:06 -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-12.txt Pages : 11 Date : 2017-06-30 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-12 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-12 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 Fri Jun 30 07:22:19 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 4B0CF120454 for ; Fri, 30 Jun 2017 07:22:18 -0700 (PDT) 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 VgasPV5ohFHb for ; Fri, 30 Jun 2017 07:22:13 -0700 (PDT) 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 459F6120227 for ; Fri, 30 Jun 2017 07:22:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ED68FBE39; Fri, 30 Jun 2017 15:22:07 +0100 (IST) 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 2C2gd2fD420R; Fri, 30 Jun 2017 15:22:07 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 75942BE24; Fri, 30 Jun 2017 15:22:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498832527; bh=Hd20k8XHBcf1J9L2rzD/3ydx5+fSCnXGRm+4FORisCU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=N37ilcL1Dqvfeqo91BULBrEYtL/a+YNVX66xbwCkh5wmtD4LypDKYIoXxJEbmL059 njMKxSmVwkEkyMlLMuSMB/IsxEpFnujkJKOgZme/XB44NwvxFpH9t5dp6RtyRsZvfL uMNX1xEfXyzW2w4Q7EY+ix2SIJ1K7TL8ljd8l58Q= To: Phillip Hallam-Baker Cc: LAMPS , Russ Housley References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> Date: Fri, 30 Jun 2017 15:22:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8xnlqDlIi5bSu9lX1tM1lBVSPE3KSj3i5" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 14:22:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8xnlqDlIi5bSu9lX1tM1lBVSPE3KSj3i5 Content-Type: multipart/mixed; boundary="7Bd8KdCkMA90Soqw7A9A78Rx28rXlR8s5"; protected-headers="v1" From: Stephen Farrell To: Phillip Hallam-Baker Cc: LAMPS , Russ Housley Message-ID: <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> Subject: Re: [lamps] Recharter Discussion References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> In-Reply-To: --7Bd8KdCkMA90Soqw7A9A78Rx28rXlR8s5 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Phill, On 29/06/17 17:54, Phillip Hallam-Baker wrote: > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell > wrote: >=20 >> >> >> On 29/06/17 16:21, Russ Housley wrote: >>> Do others have an opinion? >> >> The function sounds useful but perhaps better provided >> via an API to a CT log (not sure). The reason I'd wonder >> about that is that it's hard to see what code would >> read this new value and not want more information than >> that. A CT log API could provide more so might be more >> useful (e.g. if an RP could ask "show me your history of >> meta-data related to certs for example.com"). >> >> Probably not that relevant, but similar information would >> also exist in passive DNS DBs I guess. >> >=20 > =E2=80=8BThere is always a cut off between the standardized parts and t= he rest. >=20 > When I first proposed this, it was for human consumption. What I am > thinking about now is rather more of a hook for likely proprietary AI > systems reading it.=E2=80=8B Right, that's why a CT API seems maybe more useful and (I think, but I may be wrong), might be easier to get deployed. >=20 > =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now w= e can > eliminate what? 95% of phishing sites with free DV certs by simply > rejecting any certs less than 5 days old. =E2=80=8B >=20 >=20 > =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importan= t. But not something > we are going to be able to really work on at all, let alone standardize= > until after we have data. >=20 > All I want to do right now is to instrument so we can start collecting = data. >=20 I'm not opposed to defining such a cert extension (which I assume would be the end result) if there's likely to be deployment. But I still think that given that CT logs will have this info already, (and more, and covering >1 issuer) a new CT API may be better than putting it in certs. Cheers, S. >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --7Bd8KdCkMA90Soqw7A9A78Rx28rXlR8s5-- --8xnlqDlIi5bSu9lX1tM1lBVSPE3KSj3i5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZVl6PAAoJEC88hzaAX42ihR0H/0YBR0HZkugyvGACQZMSo+FJ P4m7B8KWiexVwqXAMawEJ+rW2/GIMyWGmZZ6Z8l5TYW2nDWidqUhn3wFKIQgmqHv Lyu/IYS0OuYqFV82BCEpyApQRsUiA3tfrbCF+gqZ9iG7ZWsx4zrJ+2Ua370YF/47 RYC5Dco9cgQ+VKEiYulchPrtII+bM9A2TiRDhWzA+X3xmlyuMojofmAcU6VI8tC4 IBybV5FLdVjxIK5FHRTRQ1N6KWDkBa/vQ6ch3Wia/en/LJahHDd7GHK08PiZIOSq g/NZzyWxcD80Jw1YnEfOuxH5+i7mNdwDf2k9NJLCyjT8mfH1AS9NkBBhJJ2mYLs= =XW6m -----END PGP SIGNATURE----- --8xnlqDlIi5bSu9lX1tM1lBVSPE3KSj3i5-- From nobody Fri Jun 30 09:27:56 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 DE01912ECC2 for ; Fri, 30 Jun 2017 09:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 ldcqY2hPEpe3 for ; Fri, 30 Jun 2017 09:27:52 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 D7C2B127136 for ; Fri, 30 Jun 2017 09:27:51 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id l13so73307769lfl.1 for ; Fri, 30 Jun 2017 09:27:51 -0700 (PDT) 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=M/W7D52ZSkwPLlO0KgogkP3cWIbjQguUXrLDOZY/jk0=; b=EOIyTsodA4cuJQERt/iSv0fz+9hKRzoXsaAhIHBFj/m7HYeE8R7y++Oc3Nzvwm905L F7CxHKwqeg5GeYoHIWpNCHuWMzjROXz3zSY7NfxNj7lOr0WDCGAgLfpaKGZ5lL8OtLiN Hu9/1fOVzVAnfm2zR8y/hXJrVTT0HMOnWyIk5j4fksnzjWlvA3XXUBksiYCQI/LEHwhP jyL2Q2ZxpL+J6XkLDv0zJxjsPNaEI1pOJ6QlrgrhK8SicMuQKXtAds2hspTUb09/DD4r byXGoUAC1wFDph9AOwK4T4/m44EmidHsLGFRiAR6eJGE77BJH4dlD3R6ZGy+oZH7F80G a0Qw== 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=M/W7D52ZSkwPLlO0KgogkP3cWIbjQguUXrLDOZY/jk0=; b=XSH/jX/CuFiTTGPuaitk/2I7z+nJ5AZ1nd0p5YU3qVPO5GPTXn0RgFKDwiA2M0CYQw 76s16+Zr+zkW4FniTST6orvb5VDVRjvDmYFDOIjZwW+3dHz20ugDuGPkq/0QCjgFaodi 6MoA15mxnoyAZQ2mGykVOkbJ9F7WjhLYmrQv9nF/oUBmQhOdjf2/a5fOtkr/uteqwoX7 YMav5YFM3EhJQfiz2V7g84Rz5zfpcBCiuu5lafll1pAVSP1WgP7tI3ieXgptjcUpjnbM MZyN7KrDEFq94GlHBrsdbesjuCAzlORM2UmbLmBWvlMExxR2No2PjP4F/kp8fN3E6TZx Hr3g== X-Gm-Message-State: AKS2vOwMrtWC13t9XFmU8mKOhhB3G09jLTCwL6nclP/akvxcfw+2lRdf s9ilxc0KUxX2pWBv8dClDILGOUUReg== X-Received: by 10.46.82.199 with SMTP id n68mr5900306lje.99.1498840070070; Fri, 30 Jun 2017 09:27:50 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Fri, 30 Jun 2017 09:27:48 -0700 (PDT) In-Reply-To: <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> From: Phillip Hallam-Baker Date: Fri, 30 Jun 2017 12:27:48 -0400 X-Google-Sender-Auth: SEVIeiUdGCyQ5oreRoUlE3PcebY Message-ID: To: Stephen Farrell Cc: LAMPS , Russ Housley Content-Type: multipart/alternative; boundary="001a113be372f3a85405532fe589" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 16:27:55 -0000 --001a113be372f3a85405532fe589 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell wrote: > > Hi Phill, > > On 29/06/17 17:54, Phillip Hallam-Baker wrote: > > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie > >> wrote: > > > >> > >> > >> On 29/06/17 16:21, Russ Housley wrote: > >>> Do others have an opinion? > >> > >> The function sounds useful but perhaps better provided > >> via an API to a CT log (not sure). The reason I'd wonder > >> about that is that it's hard to see what code would > >> read this new value and not want more information than > >> that. A CT log API could provide more so might be more > >> useful (e.g. if an RP could ask "show me your history of > >> meta-data related to certs for example.com"). > >> > >> Probably not that relevant, but similar information would > >> also exist in passive DNS DBs I guess. > >> > > > > =E2=80=8BThere is always a cut off between the standardized parts and t= he rest. > > > > When I first proposed this, it was for human consumption. What I am > > thinking about now is rather more of a hook for likely proprietary AI > > systems reading it.=E2=80=8B > > Right, that's why a CT API seems maybe more useful and (I think, > but I may be wrong), might be easier to get deployed. > > > > > =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now w= e can > > eliminate what? 95% of phishing sites with free DV certs by simply > > rejecting any certs less than 5 days old. =E2=80=8B > > > > > > =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importan= t. But not > something > > we are going to be able to really work on at all, let alone standardize > > until after we have data. > > > > All I want to do right now is to instrument so we can start collecting > data. > > > > I'm not opposed to defining such a cert extension (which I > assume would be the end result) if there's likely to be > deployment. But I still think that given that CT logs will > have this info already, (and more, and covering >1 issuer) > a new CT API may be better than putting it in certs. > =E2=80=8BI don't really want to push everything into CT. This is not inform= ation that is going to be immediately available, you would have to do a lot of log crunching to validate. Given that some browsers won't do CRLs or OCSP, I can't see them using CT for pro-active checking before they accept the connection. Where I see the value of First Issued is to allow browsers to winnow out certs that are most likely OK and concentrate checking on those that might be a bit dodgy. At any rate, putting an extension into the cert is pretty simple while changing the CT API to support short lived certs is likely to be a performance. I think that this is an easy win to get much of the return and takes the pressure off the CT end of things. --001a113be372f3a85405532fe589 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Ju= n 30, 2017 at 10:22 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie= > wrote:

Hi Phill,

On 29/06/17 17:54, Phillip Hallam-Baker wrote:
> On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 29/06/17 16:21, Russ Housley wrote:
>>> Do others have an opinion?
>>
>> The function sounds useful but perhaps better provided
>> via an API to a CT log (not sure). The reason I'd wonder
>> about that is that it's hard to see what code would
>> read this new value and not want more information than
>> that. A CT log API could provide more so might be more
>> useful (e.g. if an RP could ask "show me your history of
>> meta-data related to certs for example.com").
>>
>> Probably not that relevant, but similar information would
>> also exist in passive DNS DBs I guess.
>>
>
> =E2=80=8BThere is always a cut off between the standardized parts and = the rest.
>
> When I first proposed this, it was for human consumption. What I am > thinking about now is rather more of a hook for likely proprietary AI<= br> > systems reading it.=E2=80=8B

Right, that's why a CT API seems maybe more useful and (I think,=
but I may be wrong), might be easier to get deployed.

>
> =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now = we can
> eliminate what? 95% of phishing sites with free DV certs by simply
> rejecting any certs less than 5 days old. =E2=80=8B
>
>
> =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importa= nt. But not something
> we are going to be able to really work on at all, let alone standardiz= e
> until after we have data.
>
> All I want to do right now is to instrument so we can start collecting= data.
>

I'm not opposed to defining such a cert extension (which I
assume would be the end result) if there's likely to be
deployment. But I still think that given that CT logs will
have this info already, (and more, and covering >1 issuer)
a new CT API may be better than putting it in certs.
<= br>
=E2=80= =8BI don't really want to push everything into CT. This is not informat= ion that is going to be immediately available, you would have to do a lot o= f log crunching to validate.=C2=A0

Given that some browsers won't do CRLs or OCSP, I can't = see them using CT for pro-active checking before they accept the connection= . Where I see the value of First Issued is to allow browsers to winnow out = certs that are most likely OK and concentrate checking on those that might = be a bit dodgy.

At any ra= te, putting an extension into the cert is pretty simple while changing the = CT API to support short lived certs is likely to be a performance. I think = that this is an easy win to get much of the return and takes the pressure o= ff the CT end of things.=C2=A0
--001a113be372f3a85405532fe589-- From nobody Fri Jun 30 09:28:54 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 446C512FEE2 for ; Fri, 30 Jun 2017 09:28:52 -0700 (PDT) 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 6xew8tjmPRId for ; Fri, 30 Jun 2017 09:28:50 -0700 (PDT) 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 642B912F3D6 for ; Fri, 30 Jun 2017 09:28:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B0A0A3004D7 for ; Fri, 30 Jun 2017 12:28:49 -0400 (EDT) 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 xRLQvTS0LwAI for ; Fri, 30 Jun 2017 12:28:48 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A592D300278 for ; Fri, 30 Jun 2017 12:28:48 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 30 Jun 2017 12:28:48 -0400 References: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> To: SPASM In-Reply-To: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> Message-Id: <678040CE-455A-41FB-B877-054652348D52@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-eai-addresses-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 16:28:52 -0000 With the posting of draft-ietf-lamps-eai-addresses-12, I believe that = all WG Last Call comments have bee resolved. I will notify our Area = Director that the document is ready. Russ > On May 26, 2017, at 3:37 PM, Russ Housley = wrote: >=20 > This is the LAMPS WG Last Call for "Internationalized Email Addresses = in X.509 Certificates=E2=80=9D . = Please review the document and send your comments to the list by 9 June = 2017.=20 >=20 > Thanks, > Russ From nobody Fri Jun 30 12:18: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 2C353127867 for ; Fri, 30 Jun 2017 12:18:54 -0700 (PDT) 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 8odCdWWLQwHe for ; Fri, 30 Jun 2017 12:18:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3708126B7E for ; Fri, 30 Jun 2017 12:18:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D24E57A3309; Fri, 30 Jun 2017 19:18:51 +0000 (UTC) Date: Fri, 30 Jun 2017 19:18:51 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170630191851.GD5673@mournblade.imrryr.org> Reply-To: spasm@ietf.org References: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> <678040CE-455A-41FB-B877-054652348D52@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <678040CE-455A-41FB-B877-054652348D52@vigilsec.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-eai-addresses-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 19:18:54 -0000 On Fri, Jun 30, 2017 at 12:28:48PM -0400, Russ Housley wrote: > With the posting of draft-ietf-lamps-eai-addresses-12, I believe that all > WG Last Call comments have bee resolved. I will notify our Area Director > that the document is ready. Indeed, grammar issues aside, which I expect will be addressed by the RFC editor, looks largely done to me. It'll soon be time to resume work to support the new name type in OpenSSL. This time with rfc822Name name constraints applied to both rfc822Name and SMTPUtf8Name subjectAltNames. My only technical quibble is that I'd have preferred to also see deprecation of support for email addresses in the subject DN, subject altnames have been broadly supported for a long time. This is a non-critical issue. If there's not broad support for doing that at this time, I have no substantial issues with the -12 draft. -- Viktor. From nobody Fri Jun 30 12:21: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 BD0C8129B9B for ; Fri, 30 Jun 2017 12:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 szLM7eRYR5xI for ; Fri, 30 Jun 2017 12:21:41 -0700 (PDT) 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 EE4CC129BF3 for ; Fri, 30 Jun 2017 12:21:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 66AF13004D7 for ; Fri, 30 Jun 2017 15:21:25 -0400 (EDT) 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 NQQFQXvXWEGv for ; Fri, 30 Jun 2017 15:21:24 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6C54330043A for ; Fri, 30 Jun 2017 15:21:24 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_384F2F5B-062C-4E6A-8C33-1AB4D9BAAEA0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 30 Jun 2017 15:21:23 -0400 References: <1AE5876A-D3B4-4711-A701-03F64532F3B0@vigilsec.com> <678040CE-455A-41FB-B877-054652348D52@vigilsec.com> <20170630191851.GD5673@mournblade.imrryr.org> To: SPASM In-Reply-To: <20170630191851.GD5673@mournblade.imrryr.org> Message-Id: <37183F8C-EA96-4BC4-B13C-32C783843FA6@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-eai-addresses-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jun 2017 19:21:44 -0000 --Apple-Mail=_384F2F5B-062C-4E6A-8C33-1AB4D9BAAEA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Viktor: >=20 > My only technical quibble is that I'd have preferred to also see > deprecation of support for email addresses in the subject DN, > subject altnames have been broadly supported for a long time. This > is a non-critical issue. If there's not broad support for doing > that at this time, I have no substantial issues with the -12 draft. If you can get some CAs to support that position on list, then I think = we can work on an update to RFC 5280 in that direction. Russ --Apple-Mail=_384F2F5B-062C-4E6A-8C33-1AB4D9BAAEA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Viktor:

My only technical quibble is = that I'd have preferred to also see
deprecation of support for email = addresses in the subject DN,
subject altnames have been = broadly supported for a long time.  This
is a non-critical issue.  If there's not = broad support for doing
that at this time, I have no = substantial issues with the -12 = draft.

If = you can get some CAs to support that position on list, then I think we = can work on an update to RFC 5280 in that direction.

Russ

= --Apple-Mail=_384F2F5B-062C-4E6A-8C33-1AB4D9BAAEA0-- From nobody Fri Jun 30 21:14:36 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 EBFCB13152E for ; Fri, 30 Jun 2017 21:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 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, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 TxugJOIPl6kE for ; Fri, 30 Jun 2017 21:14:31 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B32127F0E for ; Fri, 30 Jun 2017 21:14:31 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 437A93000291E for ; Fri, 30 Jun 2017 21:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=2s8s+ek2yLT73LYeSUzlu4+5z3c=; b= duDQyiVfAQ/z0CpKRkhHNRr472fFBpYJGFPZmTRwgqxqmchk/DtupjUireJUod96 Q0516F/OA/OgetTQ94sMIN7sk+Kgwj2U7LjgGKeckp0g6VT2sofYJov7i+RWGqtB hy39h6nJ2LA3imh1thEiKJohZ+gQpXNhTTnD5mh0upM= Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 1F11D30002902 for ; Fri, 30 Jun 2017 21:14:31 -0700 (PDT) Received: by mail-wr0-f179.google.com with SMTP id c11so212107860wrc.3 for ; Fri, 30 Jun 2017 21:14:31 -0700 (PDT) X-Gm-Message-State: AKS2vOxh3ivqQfadlpPlg99xbv50p0b/mqyybI9ges/syb/6vWS/xSAP SyDA3T08sbWpOsdwkLhK05vipZUmSg== X-Received: by 10.223.146.195 with SMTP id 61mr13974780wrn.134.1498882469574; Fri, 30 Jun 2017 21:14:29 -0700 (PDT) MIME-Version: 1.0 References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> In-Reply-To: From: Ryan Sleevi Date: Sat, 01 Jul 2017 04:14:18 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Phillip Hallam-Baker , Stephen Farrell Cc: LAMPS , Russ Housley Content-Type: multipart/alternative; boundary="94eb2c0da03228c73a055339c58a" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 01 Jul 2017 04:14:34 -0000 --94eb2c0da03228c73a055339c58a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker wrote: > On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> Hi Phill, >> >> On 29/06/17 17:54, Phillip Hallam-Baker wrote: >> > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie >> >> wrote: >> > >> >> >> >> >> >> On 29/06/17 16:21, Russ Housley wrote: >> >>> Do others have an opinion? >> >> >> >> The function sounds useful but perhaps better provided >> >> via an API to a CT log (not sure). The reason I'd wonder >> >> about that is that it's hard to see what code would >> >> read this new value and not want more information than >> >> that. A CT log API could provide more so might be more >> >> useful (e.g. if an RP could ask "show me your history of >> >> meta-data related to certs for example.com"). >> >> >> >> Probably not that relevant, but similar information would >> >> also exist in passive DNS DBs I guess. >> >> >> > >> > =E2=80=8BThere is always a cut off between the standardized parts and = the rest. >> > >> > When I first proposed this, it was for human consumption. What I am >> > thinking about now is rather more of a hook for likely proprietary AI >> > systems reading it.=E2=80=8B >> >> Right, that's why a CT API seems maybe more useful and (I think, >> but I may be wrong), might be easier to get deployed. >> >> > >> > =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now = we can >> > eliminate what? 95% of phishing sites with free DV certs by simply >> > rejecting any certs less than 5 days old. =E2=80=8B > > Who is we? Is this a statement of what you believe browsers should do, versus will? Have you heard of or can provide evidence for any expression of support, from any browser, for this philosophy? >> > >> > >> > =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importa= nt. But not >> something >> > we are going to be able to really work on at all, let alone standardiz= e >> > until after we have data. >> > >> > All I want to do right now is to instrument so we can start collecting >> data. >> > >> >> I'm not opposed to defining such a cert extension (which I >> assume would be the end result) if there's likely to be >> deployment. But I still think that given that CT logs will >> have this info already, (and more, and covering >1 issuer) >> a new CT API may be better than putting it in certs. >> > > =E2=80=8BI don't really want to push everything into CT. This is not info= rmation > that is going to be immediately available, you would have to do a lot of > log crunching to validate. > > Given that some browsers won't do CRLs or OCSP, I can't see them using CT > for pro-active checking before they accept the connection. Where I see th= e > value of First Issued is to allow browsers to winnow out certs that are > most likely OK and concentrate checking on those that might be a bit dodg= y. > Are you aware of any browsers interested in this? This feels very much like LogoType - which was intended for browsers (among others) and rightfully not widely implemented. > At any rate, putting an extension into the cert is pretty simple while > changing the CT API to support short lived certs is likely to be a > performance. I think that this is an easy win to get much of the return a= nd > takes the pressure off the CT end of things. > CT already has to deal with this. It does seem you're conflating two unrelated things though, but perhaps I'm misunderstanding. Perhaps it could be useful if you could explain what you believe the browser security model to be, and how this supports what browsers are doing or have expressed support for. I do not see any value to this as an extension - and I can see undesirable (and unreliable) data being added by CAs - so I'm curious to understand why using CT is insufficient, especially for the proposed browser-run machine learning reputation determination. --94eb2c0da03228c73a055339c58a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jun 30, 2017 = at 9:27 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
On Fri, Jun = 30, 2017 at 10:22 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Phill,

On 29/06/17 17:54, Phillip Hallam-Baker wrote:
> On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 29/06/17 16:21, Russ Housley wrote:
>>> Do others have an opinion?
>>
>> The function sounds useful but perhaps better provided
>> via an API to a CT log (not sure). The reason I'd wonder
>> about that is that it's hard to see what code would
>> read this new value and not want more information than
>> that. A CT log API could provide more so might be more
>> useful (e.g. if an RP could ask "show me your history of
>> meta-data related to certs for example.com").
>>
>> Probably not that relevant, but similar information would
>> also exist in passive DNS DBs I guess.
>>
>
> =E2=80=8BThere is always a cut off between the standardized parts and = the rest.
>
> When I first proposed this, it was for human consumption. What I am > thinking about now is rather more of a hook for likely proprietary AI<= br> > systems reading it.=E2=80=8B

Right, that's why a CT API seems maybe more useful and (I think,=
but I may be wrong), might be easier to get deployed.

>
> =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now = we can
> eliminate what? 95% of phishing sites with free DV certs by simply
> rejecting any certs less than 5 days old. =E2=80=8B

Who is we?

Is this a = statement of what you believe browsers should do, versus will? Have you hea= rd of or can provide evidence for any expression of support, from any brows= er, for this philosophy?


>
>
> =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importa= nt. But not something
> we are going to be able to really work on at all, let alone standardiz= e
> until after we have data.
>
> All I want to do right now is to instrument so we can start collecting= data.
>

I'm not opposed to defining such a cert extension (which I
assume would be the end result) if there's likely to be
deployment. But I still think that given that CT logs will
have this info already, (and more, and covering >1 issuer)
a new CT API may be better than putting it in certs.
<= br>
=E2= =80=8BI don't really want to push everything into CT. This is not infor= mation that is going to be immediately available, you would have to do a lo= t of log crunching to validate.=C2=A0

Given that some browsers won't do CRLs or OCSP, I can'= t see them using CT for pro-active checking before they accept the connecti= on. Where I see the value of First Issued is to allow browsers to winnow ou= t certs that are most likely OK and concentrate checking on those that migh= t be a bit dodgy.

Are you aware of any browsers interested in = this? This feels very much like LogoType - which was intended for browsers = (among others) and rightfully not widely implemented.

=
At any rate,= putting an extension into the cert is pretty simple while changing the CT = API to support short lived certs is likely to be a performance. I think tha= t this is an easy win to get much of the return and takes the pressure off = the CT end of things.=C2=A0

CT already has to deal with this. = It does seem you're conflating two unrelated things though, but perhaps= I'm misunderstanding.

Perhaps it could be useful if you could explain what you believe the bro= wser security model to be, and how this supports what browsers are doing or= have expressed support for.

<= div dir=3D"auto">I do not see any value to this as an extension - and I can= see undesirable (and unreliable) data being added by CAs - so I'm curi= ous to understand why using CT is insufficient, especially for the proposed= browser-run machine learning reputation determination. --94eb2c0da03228c73a055339c58a-- From nobody Fri Jun 30 21:58:18 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 BCAB613153B for ; Fri, 30 Jun 2017 21:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 ebaCxA9bX-Ql for ; Fri, 30 Jun 2017 21:58:14 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 4AA241243F3 for ; Fri, 30 Jun 2017 21:58:14 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id l13so79650934lfl.1 for ; Fri, 30 Jun 2017 21:58:14 -0700 (PDT) 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=7Y1pOxgw/wCBmHiLwLLC4JuqLBoj1Nm/e9dVwyDVLPk=; b=kLWwJD6ceGjNr3xpBU0e118qjBAFFcQOIlUVbNCU14me8Pn/RTPtY6wjtZ35wxzKQE rm7/ISsg6HWmm/ga9TbrsI8kt3Tp364omoeRYQilOi1t51tNfmJZYHPvQS57A7N7g8BG 5Kw7KXVYDYgz+AhWqNY91FQH1CmM0Ibw0FqEaQeZmKhSnx/8Anmw70xq3CGc5DmySvPi 16Nde/erkQ5K3bWPlMJikA0tuTVrGxDCNVZuVZGWEMZI0W3sxEvccYe/4aSOXIJPn19a O3xIkqPHAuDgBhPnFg2+fqnSzbFfDlDpezgVCZtoyZdCD00kamqZzKuflmO66VT5B8Ui IR9w== 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=7Y1pOxgw/wCBmHiLwLLC4JuqLBoj1Nm/e9dVwyDVLPk=; b=PqOM6kf/bPkcqdRwf1o8ecs2Hyw/BmhKuH6oNE/PpskQzTUbiD5kvALr0gen5Fhtuk /OFCM0fL84wns/9PYiCFUJHRDwdT0GGWivY99pelieclim5O6eNJMXjHZg1u1JWu7H3H YbFPaq8rQ92SovtBHuvGASPKruy1f8fuGJ52p9RQWARlKFXyukkUQLQ2widJL736Di/x cxQ/6wWP4iie9rRhsiWAsfxtNOrkpIv6FBRmgDRr+T9/YCSkS37/rB/9vjVNhr9YRJi4 IAOYoIzBwGbCoNbDm0bvocLG7j+9uJm8K9vyYQPm9FhSumO/CoxI5vtoTdpmJDasV3ol IPmQ== X-Gm-Message-State: AKS2vOwmWQxeT2cy7NlIfOe/UmsEp8QMsaWVHW5lxsFAlAWtthAS/DyV 1tfs+b9IRerxOoDZTRL/aTxltX6fUQ== X-Received: by 10.46.84.1 with SMTP id i1mr6533984ljb.131.1498885092544; Fri, 30 Jun 2017 21:58:12 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Fri, 30 Jun 2017 21:58:11 -0700 (PDT) In-Reply-To: References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> From: Phillip Hallam-Baker Date: Sat, 1 Jul 2017 00:58:11 -0400 X-Google-Sender-Auth: kdE4QziZAi00B_545M1ukQI7sTk Message-ID: To: Ryan Sleevi Cc: Stephen Farrell , LAMPS , Russ Housley Content-Type: multipart/alternative; boundary="f403045fbb06801eab05533a6184" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 01 Jul 2017 04:58:18 -0000 --f403045fbb06801eab05533a6184 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BSince Comodo distributes a browser, at least one browser is intere= sted. Given that you seem entirely unconcerned by 16,000 fake paypal sites a certain CA has issued certs for, it is not surprising that you see no reason to make any changes. On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi wrote: > > On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> wrote: >> >>> >>> Hi Phill, >>> >>> On 29/06/17 17:54, Phillip Hallam-Baker wrote: >>> > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell < >>> stephen.farrell@cs.tcd.ie >>> >> wrote: >>> > >>> >> >>> >> >>> >> On 29/06/17 16:21, Russ Housley wrote: >>> >>> Do others have an opinion? >>> >> >>> >> The function sounds useful but perhaps better provided >>> >> via an API to a CT log (not sure). The reason I'd wonder >>> >> about that is that it's hard to see what code would >>> >> read this new value and not want more information than >>> >> that. A CT log API could provide more so might be more >>> >> useful (e.g. if an RP could ask "show me your history of >>> >> meta-data related to certs for example.com"). >>> >> >>> >> Probably not that relevant, but similar information would >>> >> also exist in passive DNS DBs I guess. >>> >> >>> > >>> > =E2=80=8BThere is always a cut off between the standardized parts and= the rest. >>> > >>> > When I first proposed this, it was for human consumption. What I am >>> > thinking about now is rather more of a hook for likely proprietary AI >>> > systems reading it.=E2=80=8B >>> >>> Right, that's why a CT API seems maybe more useful and (I think, >>> but I may be wrong), might be easier to get deployed. >>> >>> > >>> > =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now= we can >>> > eliminate what? 95% of phishing sites with free DV certs by simply >>> > rejecting any certs less than 5 days old. =E2=80=8B >> >> > Who is we? > > Is this a statement of what you believe browsers should do, versus will? > Have you heard of or can provide evidence for any expression of support, > from any browser, for this philosophy? > > >>> > >>> > >>> > =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be import= ant. But not >>> something >>> > we are going to be able to really work on at all, let alone standardi= ze >>> > until after we have data. >>> > >>> > All I want to do right now is to instrument so we can start collectin= g >>> data. >>> > >>> >>> I'm not opposed to defining such a cert extension (which I >>> assume would be the end result) if there's likely to be >>> deployment. But I still think that given that CT logs will >>> have this info already, (and more, and covering >1 issuer) >>> a new CT API may be better than putting it in certs. >>> >> >> =E2=80=8BI don't really want to push everything into CT. This is not inf= ormation >> that is going to be immediately available, you would have to do a lot of >> log crunching to validate. >> >> Given that some browsers won't do CRLs or OCSP, I can't see them using C= T >> for pro-active checking before they accept the connection. Where I see t= he >> value of First Issued is to allow browsers to winnow out certs that are >> most likely OK and concentrate checking on those that might be a bit dod= gy. >> > > Are you aware of any browsers interested in this? This feels very much > like LogoType - which was intended for browsers (among others) and > rightfully not widely implemented. > > >> At any rate, putting an extension into the cert is pretty simple while >> changing the CT API to support short lived certs is likely to be a >> performance. I think that this is an easy win to get much of the return = and >> takes the pressure off the CT end of things. >> > > CT already has to deal with this. It does seem you're conflating two > unrelated things though, but perhaps I'm misunderstanding. > > Perhaps it could be useful if you could explain what you believe the > browser security model to be, and how this supports what browsers are doi= ng > or have expressed support for. > > I do not see any value to this as an extension - and I can see undesirabl= e > (and unreliable) data being added by CAs - so I'm curious to understand w= hy > using CT is insufficient, especially for the proposed browser-run machine > learning reputation determination. > --f403045fbb06801eab05533a6184 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2= =80=8BSince Comodo distributes a browser, at least one browser is intereste= d.

Given that you seem en= tirely unconcerned by 16,000 fake paypal sites a certain CA has issued cert= s for, it is not surprising that you see no reason to make any changes.



On Sat, Jul 1, 2017 at 12:1= 4 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-B= aker <phill@h= allambaker.com> wrote:
=
On Fri, Jun 30, 2017 = at 10:22 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:<= br>

Hi Phill,

On 29/06/17 17:54, Phillip Hallam-Baker wrote:
> On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 29/06/17 16:21, Russ Housley wrote:
>>> Do others have an opinion?
>>
>> The function sounds useful but perhaps better provided
>> via an API to a CT log (not sure). The reason I'd wonder
>> about that is that it's hard to see what code would
>> read this new value and not want more information than
>> that. A CT log API could provide more so might be more
>> useful (e.g. if an RP could ask "show me your history of
>> meta-data related to certs for example.com").
>>
>> Probably not that relevant, but similar information would
>> also exist in passive DNS DBs I guess.
>>
>
> =E2=80=8BThere is always a cut off between the standardized parts and = the rest.
>
> When I first proposed this, it was for human consumption. What I am > thinking about now is rather more of a hook for likely proprietary AI<= br> > systems reading it.=E2=80=8B

Right, that's why a CT API seems maybe more useful and (I think,=
but I may be wrong), might be easier to get deployed.

>
> =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now = we can
> eliminate what? 95% of phishing sites with free DV certs by simply
> rejecting any certs less than 5 days old. =E2=80=8B

Who is we?

Is this a statement of what you believe browsers should do, versus will? = Have you heard of or can provide evidence for any expression of support, fr= om any browser, for this philosophy?

=

>
>
> =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importa= nt. But not something
> we are going to be able to really work on at all, let alone standardiz= e
> until after we have data.
>
> All I want to do right now is to instrument so we can start collecting= data.
>

I'm not opposed to defining such a cert extension (which I
assume would be the end result) if there's likely to be
deployment. But I still think that given that CT logs will
have this info already, (and more, and covering >1 issuer)
a new CT API may be better than putting it in certs.
<= br>
=E2= =80=8BI don't really want to push everything into CT. This is not infor= mation that is going to be immediately available, you would have to do a lo= t of log crunching to validate.=C2=A0

Given that some browsers won't do CRLs or OCSP, I can'= t see them using CT for pro-active checking before they accept the connecti= on. Where I see the value of First Issued is to allow browsers to winnow ou= t certs that are most likely OK and concentrate checking on those that migh= t be a bit dodgy.

Are you aware of any browsers interes= ted in this? This feels very much like LogoType - which was intended for br= owsers (among others) and rightfully not widely implemented.


At any rate, putting an extension into the cert is pretty simpl= e while changing the CT API to support short lived certs is likely to be a = performance. I think that this is an easy win to get much of the return and= takes the pressure off the CT end of things.=C2=A0
=

CT = already has to deal with this. It does seem you're conflating two unrel= ated things though, but perhaps I'm misunderstanding.

Perhaps it could be useful if you could e= xplain what you believe the browser security model to be, and how this supp= orts what browsers are doing or have expressed support for.

I do not see any value to= this as an extension - and I can see undesirable (and unreliable) data bei= ng added by CAs - so I'm curious to understand why using CT is insuffic= ient, especially for the proposed browser-run machine learning reputation d= etermination.

--f403045fbb06801eab05533a6184-- From nobody Fri Jun 30 23:20:32 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 03E8112EC15 for ; Fri, 30 Jun 2017 23:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 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, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 8um2R1nXUwNV for ; Fri, 30 Jun 2017 23:20:28 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23501127863 for ; Fri, 30 Jun 2017 23:20:28 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id AA08320047613 for ; Fri, 30 Jun 2017 23:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=CJUiB9IdFu2PgK2/Sh7vedbvfqY=; b= UC/fX60gnwcyIOEPFgTHw2Lw1N7tc29PgkURgCUtrunZKlrezx49kkvKOovwL8Wc 85cClmyOFmlurKGLfYm0FBJylZ36VdVCe8KJhlppbrV3RQak2/RlH1frnSUKvfoI wCH50M98PnR+CHX6xM3e4V0conf89WGpCJ3zTc/PvYU= Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 635B820047612 for ; Fri, 30 Jun 2017 23:20:27 -0700 (PDT) Received: by mail-wr0-f171.google.com with SMTP id r103so212780548wrb.0 for ; Fri, 30 Jun 2017 23:20:27 -0700 (PDT) X-Gm-Message-State: AKS2vOzlsReb1U63+qNHz8kYkntR+cSEJbxNfVT7GmN/TlYo6J+Hccnr IXO0DFDbAll9Sxi5KmguCAJxlQIKLQ== X-Received: by 10.223.171.25 with SMTP id q25mr29126455wrc.89.1498890025931; Fri, 30 Jun 2017 23:20:25 -0700 (PDT) MIME-Version: 1.0 References: <6D0438F4-5C3B-4F28-A8FB-16B6CFA1C7CA@vigilsec.com> <7298935b-3b4d-4794-8f40-acb188690e87@cs.tcd.ie> In-Reply-To: From: Ryan Sleevi Date: Sat, 01 Jul 2017 06:20:15 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Phillip Hallam-Baker , Ryan Sleevi Cc: LAMPS , Russ Housley , Stephen Farrell Content-Type: multipart/alternative; boundary="94eb2c1b5c268d9a4005533b879d" Archived-At: Subject: Re: [lamps] Recharter Discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 01 Jul 2017 06:20:31 -0000 --94eb2c1b5c268d9a4005533b879d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I do hope we can keep the discussion professional and focused on the technical matters, and without attributing things that were not said. It does not sound like you wish to engage in the technical discussion of the merits, or to explain why this problem should be solved as a certificate extension, as the previous questions were left unaddressed. As it stands, I would prefer not to see this adopted in a recharter, without technical justification. It does seem like, at present, it could work as an individual draft that Comodo could implement and establish its technical virtue and value, and perhaps then bring compelling justification forward, perhaps with greater implementer interest. On Fri, Jun 30, 2017 at 10:58 PM Phillip Hallam-Baker wrote: > =E2=80=8BSince Comodo distributes a browser, at least one browser is inte= rested. > > Given that you seem entirely unconcerned by 16,000 fake paypal sites a > certain CA has issued certs for, it is not surprising that you see no > reason to make any changes. > > > > On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi wrote= : > >> >> On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker < >> phill@hallambaker.com> wrote: >> >>> On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell < >>> stephen.farrell@cs.tcd.ie> wrote: >>> >>>> >>>> Hi Phill, >>>> >>>> On 29/06/17 17:54, Phillip Hallam-Baker wrote: >>>> > On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell < >>>> stephen.farrell@cs.tcd.ie >>>> >> wrote: >>>> > >>>> >> >>>> >> >>>> >> On 29/06/17 16:21, Russ Housley wrote: >>>> >>> Do others have an opinion? >>>> >> >>>> >> The function sounds useful but perhaps better provided >>>> >> via an API to a CT log (not sure). The reason I'd wonder >>>> >> about that is that it's hard to see what code would >>>> >> read this new value and not want more information than >>>> >> that. A CT log API could provide more so might be more >>>> >> useful (e.g. if an RP could ask "show me your history of >>>> >> meta-data related to certs for example.com"). >>>> >> >>>> >> Probably not that relevant, but similar information would >>>> >> also exist in passive DNS DBs I guess. >>>> >> >>>> > >>>> > =E2=80=8BThere is always a cut off between the standardized parts an= d the >>>> rest. >>>> > >>>> > When I first proposed this, it was for human consumption. What I am >>>> > thinking about now is rather more of a hook for likely proprietary A= I >>>> > systems reading it.=E2=80=8B >>>> >>>> Right, that's why a CT API seems maybe more useful and (I think, >>>> but I may be wrong), might be easier to get deployed. >>>> >>>> > >>>> > =E2=80=8BSecurity is risk mitigation, not risk elimination. Right no= w we can >>>> > eliminate what? 95% of phishing sites with free DV certs by simply >>>> > rejecting any certs less than 5 days old. =E2=80=8B >>> >>> >> Who is we? >> >> Is this a statement of what you believe browsers should do, versus will? >> Have you heard of or can provide evidence for any expression of support, >> from any browser, for this philosophy? >> >> >>>> > >>>> > >>>> > =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be impor= tant. But not >>>> something >>>> > we are going to be able to really work on at all, let alone >>>> standardize >>>> > until after we have data. >>>> > >>>> > All I want to do right now is to instrument so we can start >>>> collecting data. >>>> > >>>> >>>> I'm not opposed to defining such a cert extension (which I >>>> assume would be the end result) if there's likely to be >>>> deployment. But I still think that given that CT logs will >>>> have this info already, (and more, and covering >1 issuer) >>>> a new CT API may be better than putting it in certs. >>>> >>> >>> =E2=80=8BI don't really want to push everything into CT. This is not in= formation >>> that is going to be immediately available, you would have to do a lot o= f >>> log crunching to validate. >>> >>> Given that some browsers won't do CRLs or OCSP, I can't see them using >>> CT for pro-active checking before they accept the connection. Where I s= ee >>> the value of First Issued is to allow browsers to winnow out certs that= are >>> most likely OK and concentrate checking on those that might be a bit do= dgy. >>> >> >> Are you aware of any browsers interested in this? This feels very much >> like LogoType - which was intended for browsers (among others) and >> rightfully not widely implemented. >> >> >>> At any rate, putting an extension into the cert is pretty simple while >>> changing the CT API to support short lived certs is likely to be a >>> performance. I think that this is an easy win to get much of the return= and >>> takes the pressure off the CT end of things. >>> >> >> CT already has to deal with this. It does seem you're conflating two >> unrelated things though, but perhaps I'm misunderstanding. >> >> Perhaps it could be useful if you could explain what you believe the >> browser security model to be, and how this supports what browsers are do= ing >> or have expressed support for. >> >> I do not see any value to this as an extension - and I can see >> undesirable (and unreliable) data being added by CAs - so I'm curious to >> understand why using CT is insufficient, especially for the proposed >> browser-run machine learning reputation determination. >> > > --94eb2c1b5c268d9a4005533b879d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do hope we can keep the discussion professional an= d focused on the technical matters, and without attributing things that wer= e not said.

It does not = sound like you wish to engage in the technical discussion of the merits, or= to explain why this problem should be solved as a certificate extension, a= s the previous questions were left unaddressed.

=
As it stands, I would prefer not to see this adopte= d in a recharter, without technical justification. It does seem like, at pr= esent, it could work as an individual draft that Comodo could implement and= establish its technical virtue and value, and perhaps then bring compellin= g justification forward, perhaps with greater implementer interest.
On Fri, Jun 30, 2017 at 10:58 PM Phillip = Hallam-Baker <phill@hallambaker= .com> wrote:
=E2=80=8BSince Comodo distribu= tes a browser, at least one browser is interested.

Given that you seem entirely unconcerned by 16,00= 0 fake paypal sites a certain CA has issued certs for, it is not surprising= that you see no reason to make any changes.



On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi <= ryan-ietf@sleevi.= com> wrote:

On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
On Fri, Jun 30, 2017 at 10:22 AM, Ste= phen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Phill,

On 29/06/17 17:54, Phillip Hallam-Baker wrote:
> On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 29/06/17 16:21, Russ Housley wrote:
>>> Do others have an opinion?
>>
>> The function sounds useful but perhaps better provided
>> via an API to a CT log (not sure). The reason I'd wonder
>> about that is that it's hard to see what code would
>> read this new value and not want more information than
>> that. A CT log API could provide more so might be more
>> useful (e.g. if an RP could ask "show me your history of
>> meta-data related to certs for example.com").
>>
>> Probably not that relevant, but similar information would
>> also exist in passive DNS DBs I guess.
>>
>
> =E2=80=8BThere is always a cut off between the standardized parts and = the rest.
>
> When I first proposed this, it was for human consumption. What I am > thinking about now is rather more of a hook for likely proprietary AI<= br> > systems reading it.=E2=80=8B

Right, that's why a CT API seems maybe more useful and (I think,=
but I may be wrong), might be easier to get deployed.

>
> =E2=80=8BSecurity is risk mitigation, not risk elimination. Right now = we can
> eliminate what? 95% of phishing sites with free DV certs by simply
> rejecting any certs less than 5 days old. =E2=80=8B

Who is we?

Is this a statement of what you believe browsers should do, versus will? = Have you heard of or can provide evidence for any expression of support, fr= om any browser, for this philosophy?


>
>
> =E2=80=8BWhat we do next with the =E2=80=8Bdata is going to be importa= nt. But not something
> we are going to be able to really work on at all, let alone standardiz= e
> until after we have data.
>
> All I want to do right now is to instrument so we can start collecting= data.
>

I'm not opposed to defining such a cert extension (which I
assume would be the end result) if there's likely to be
deployment. But I still think that given that CT logs will
have this info already, (and more, and covering >1 issuer)
a new CT API may be better than putting it in certs.
<= br>
=E2= =80=8BI don't really want to push everything into CT. This is not infor= mation that is going to be immediately available, you would have to do a lo= t of log crunching to validate.=C2=A0

Given that some browsers won't do CRLs or OCSP, I can'= t see them using CT for pro-active checking before they accept the connecti= on. Where I see the value of First Issued is to allow browsers to winnow ou= t certs that are most likely OK and concentrate checking on those that migh= t be a bit dodgy.

Are you aware of any browsers interes= ted in this? This feels very much like LogoType - which was intended for br= owsers (among others) and rightfully not widely implemented.


At any rate, putting an extension into the cert is pretty simple while cha= nging the CT API to support short lived certs is likely to be a performance= . I think that this is an easy win to get much of the return and takes the = pressure off the CT end of things.=C2=A0

CT already has= to deal with this. It does seem you're conflating two unrelated things= though, but perhaps I'm misunderstanding.

<= /div>
Perhaps it could be useful if you could explain what= you believe the browser security model to be, and how this supports what b= rowsers are doing or have expressed support for.
I do not see any value to this as an e= xtension - and I can see undesirable (and unreliable) data being added by C= As - so I'm curious to understand why using CT is insufficient, especia= lly for the proposed browser-run machine learning reputation determination.=

--94eb2c1b5c268d9a4005533b879d--