From nobody Fri Nov 2 18:16:02 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4A5130E02 for ; Fri, 2 Nov 2018 18:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WRMeNGzP5vr for ; Fri, 2 Nov 2018 18:15:57 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 65CCC128D09 for ; Fri, 2 Nov 2018 18:15:57 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id o2-v6so2485821lfl.13 for ; Fri, 02 Nov 2018 18:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mldo5AKqZe+oGT5mjVSxhNSQ9PQ1SvTUcKzQK4Wg8i0=; b=JFxgKZ4SKvjyyw/3Nd2DRPpt7aM1W/xSRDhBr33BNbcEmN0VC81YNXCisv5zumixq1 XpKrIlVgoyY3K1RfQxGT1OTBMUujFUP/BYjaJSSM9ykQx+dFV7ot+mp8Xil6Rb+WFrnP aRUBYV8qzScZDMgoNlSIu9XQyJJEDk7VnMHXawM1Y2WPiNB5UC6o3eP3xxZnkZhLn3hJ nCv1z1KlFQBaMpWKBQByeFXoIig97533fQRjVDO5gf0cImACU4HmJDZbix0rODAMdX7n Pjo2purFs93gOizICM34pI6yEBq6DzMviT2X1DD5S8FVqA9ls8MsddKzJJ26E2u/kGcs npYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mldo5AKqZe+oGT5mjVSxhNSQ9PQ1SvTUcKzQK4Wg8i0=; b=gEilWwH6/m+xllgL3IAoj8hy+0mfKLRrHqTFY/10+rRA+Kc0yoZ4nzQ2dnlID7hsSD pNPO2eAa32PiJY9HP8PffE6F/4kr9fDgHv6drTPlWgv+hbLY7RentuefS1LSvxVl//ZW Juilr9Q2a6N73Dj6XPJxHRieBtV7v2rDeyy4EWcOfTJJazfgfcMb97+ayJVpeCI6BmWf SB8B3F0siBfCpx/xwfnM4a/Gvvl+GNHvV07KvbWFW84xl2UDfVEx42upSjbloJdB2+2Z vROpqKwVF++EdJO2Q3JFs6/jgaz3MbHJee8VI0hPbyzwyKLB6wVJsoeaOetN4BdjvUij tAag== X-Gm-Message-State: AGRZ1gL+/ENhOdbc8MLjltB0kq1I/9NKn91A0rRy60BoSqZ+66ypSt9B YBRAyPCR+4dLwtZpLB3yMOuou5dQKvqtcwYP15CgcQ== X-Google-Smtp-Source: AJdET5fbnOrLa83pyV4o7RPD1m1k5xPylIGAMSLF4HRMjGJfsnl+gpGzRloodLs9wWFJPyvc6UkXvzleismsSP8uthA= X-Received: by 2002:a19:d857:: with SMTP id p84mr5435307lfg.44.1541207755156; Fri, 02 Nov 2018 18:15:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 2 Nov 2018 18:15:43 -0700 Message-ID: To: SecEvent Cc: Yaron Sheffer , Mike Jones , Annabelle Richard Content-Type: multipart/alternative; boundary="000000000000c573800579b86409" Archived-At: Subject: Re: [Id-event] IETF 103 secevent agenda X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 01:16:00 -0000 --000000000000c573800579b86409 Content-Type: text/plain; charset="UTF-8" Our agenda (unless we change it in the meeting!) is below Mike / Annabelle: please email Yaron and I a status on your presentations. Thanks! On Mon, Oct 22, 2018 at 4:49 PM Dick Hardt wrote: > Here is the draft agenda, let us know if you have any suggested changes. > > Agenda: > 5 - agenda bashing - chairs > 30 - SET Subject Identifiers - Annabelle > 30 - Push SET Distribution - Annabelle > 30 - Poll SET Distribution - Mike > 15 - New work or charter change - chairs > 10 - Any other business - chairs > > --000000000000c573800579b86409 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Our agenda (unless we change it in the meeting!) is below<= div>
Mike / Annabelle: please email Yaron and I a status on y= our presentations. Thanks!

On Mon, Oct 22, 2018 at 4:49 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Here is the draft agenda, let u= s know if you have any suggested changes.

Age= nda:
=C2=A05 -=C2=A0agenda=C2=A0bashing - chairs
30 - SET= Subject Identifiers - Annabelle
30 - Push SET Distribution - Annabelle<= br>30 - Poll SET Distribution - Mike
15 - New work or charter change - = chairs
10 - Any other business - chairs

--000000000000c573800579b86409-- From nobody Tue Nov 6 18:27:21 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFDD126CB6 for ; Tue, 6 Nov 2018 18:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 (1024-bit key) header.d=microsoft.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 AvmZOaOwxFB7 for ; Tue, 6 Nov 2018 18:27:17 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD3C127332 for ; Tue, 6 Nov 2018 18:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=47HOGpBDkMSQLfZ/JjRZo3lEF60typ8q4li1UcBFTIY=; b=hhdMMcID9OnNPy1H4+p39bnv4EmLC3wXa17sdLOMyfsOVk8Tl7ldE4jn7Eq48+8wA/Yxp3yBMJe1C0gnTdkO4guZKUdfJdeZF/ASe+XJErThOOxVAXIk5Q8OxxmPezHETjfF/PYoyrUpLhA3vD7ywDXNh4qRVgoTESlJnlUwyzs= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0401.namprd00.prod.outlook.com (52.132.20.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1357.0; Wed, 7 Nov 2018 02:27:16 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::9968:f76e:fc46:f96]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::9968:f76e:fc46:f96%7]) with mapi id 15.20.1357.000; Wed, 7 Nov 2018 02:27:15 +0000 From: Mike Jones To: "id-event@ietf.org" Thread-Topic: Please add "acct" as a subject identifier type Thread-Index: AdR2QFZB3P6n6deASIeX0MSSOWcToQ== Date: Wed, 7 Nov 2018 02:27:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:876:83ab:78c8:7c2d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0401; 6:F4rkWtaBewf2wFcNA/GLn0X+sOiAgj+rdkmFjSq77JDNygKA5/fGbIuB51fl3D4nioYzLsRKvRpS0e4rUf0LyET3VpcG6T8oocNesfQBhS4ZzyarvxWWKjecpqbKwC7r0qOjJGuamxM3JvEsgUN+sinl1lqWdpdqhP37oc8EcB+xCRum5M0zbk7/cX8zFcbXrcbNMfSb7FeC4Gsanv0UnSGVs7Q1foqvwNGonqmyxyOsNDDX29LXzi2bgrBiv2qT85n8LLxP5x882Pq/NB9OljSX0RL9kanBPcom6aqaa/8Xf9Wh4hARW1qvY/RyxKaGguBZUvrFvrF9h4SN2+NLZxEtSaDMPaokQmOKiD6U8BTffHtXRCbpOKGKpUJAXb0rBsmWAakpbxgbICI58CWmM3jRZtRk7pUJY8oSdI8YqV5g5zGpUz+A2OmoFVUrLMvjlpFWvQKATYWp+Q3dXoXOUw==; 5:/rjQFXcu4+p9RZwTq/iC4SxFM4lBtmX8FuvGaETVkJv1rj1YVI6fSg2jdtOhiwjLjBWtdpRXrCudfL9A+FU6MnEjG5l07CggFwDx0/aDpltrp0cP3dvVt1k4ygJNcvoIF86wclmDPaOqrZxu4MLUR6/7qYw3yhKtQIc/JUeBJP4=; 7:87CObFi2dodmu2DLIhcNbJQVy1o3sqMMbu3cRd8yzxbi0qsCjk1yIY9D6FePKvNE7icMf+9qlitU59vpifoyV4eF6hW4TVDnLODn3miX+O8f6gAXzcT7kDQDiSYMGcEJ13Qnh5S0ErLaa4wJl98rxw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e53dc635-2d87-4304-3854-08d644588898 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR00MB0401; x-ms-traffictypediagnostic: BL0PR00MB0401: x-ms-exchange-purlcount: 3 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231382)(944501410)(2018427008)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BL0PR00MB0401; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0401; x-forefront-prvs: 08497C3D99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(136003)(39860400002)(396003)(199004)(189003)(7696005)(316002)(2900100001)(186003)(8990500004)(22452003)(2906002)(6916009)(478600001)(6506007)(106356001)(606006)(8676002)(2501003)(10290500003)(105586002)(10090500001)(102836004)(72206003)(8936002)(5660300001)(97736004)(33656002)(2351001)(14454004)(46003)(86362001)(486006)(71200400001)(74316002)(53936002)(790700001)(86612001)(71190400001)(68736007)(6436002)(5640700003)(476003)(9686003)(236005)(55016002)(6116002)(54896002)(6306002)(14444005)(7736002)(99286004)(81156014)(25786009)(256004)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0401; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DHlEuEpT5Ahf4XOMExrs0kot6x4lYottvvlFGg+bDYdixeL7i1to3SMzQ9gt6dthS15dAQbaH//XM2aEL9f1AYM+0knPjYZLxYj//pV8owyEgsalW+s953Kcvxx1MaQlCYKR9nfvjuX2ZqaGmOS60O9tyaCGkZ6abIRfdiMRL3loMJ58rlMxsoPWtmrXMCZSq06eVMHFpg3gBYMamxlLJqydK3TonpQFvnrWbCI8sySgCaeDkeitdfUcyJY3mxwdoOW1rdlpzNbmQoXp79cAArmmF9BIRsC4NFkc9V+5DRoELW2olssZM8zghOFuLcUkaSbOpjJ12u4pxfNMCVlb+QcFm228U1X2kx+vQq0S3+U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB029239831F492D6133D916BDF5C40BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e53dc635-2d87-4304-3854-08d644588898 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 02:27:15.8011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0401 Archived-At: Subject: [Id-event] Please add "acct" as a subject identifier type X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 02:27:20 -0000 --_000_BL0PR00MB029239831F492D6133D916BDF5C40BL0PR00MB0292namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per the discussion at the working group meeting in Bangkok, please add "acc= t" as a subject identifier type in draft-ietf-secevent-subject-identifiers.= Its value would be an RFC 7565 value= without the "acct:" prefix. This is important for identifying user accounts that are not e-mail address= es. For instance, I'm "selfissued" at Twitter. This could be represented = as: "acct": "selfissued@twitter.com" I'd suggest the description "An account identified with the specified RFC 7= 565 account identifier, omitting the "acct:" prefix". Note that an acct identifier is explicitly not an e-mail address. Thanks, -- Mike --_000_BL0PR00MB029239831F492D6133D916BDF5C40BL0PR00MB0292namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Per the discussion at the working group meeting in B= angkok, please add “acct” as a subject identifier type in draft= -ietf-secevent-subject-identifiers.  Its value would be an RFC 7565 value without = the “acct:” prefix.

 

This is important for identifying user accounts that= are not e-mail addresses.  For instance, I’m “selfissued&= #8221; at Twitter.  This could be represented as:

        &nbs= p;     “acct”: “selfissued@twitter.co= m”

 

I’d suggest the description “An account = identified with the specified RFC 7565 account identifier, omitting the = 220;acct:” prefix”.

 

Note that an acct identifier is explicitly not an e-= mail address.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

--_000_BL0PR00MB029239831F492D6133D916BDF5C40BL0PR00MB0292namp_-- From nobody Tue Nov 6 18:51:19 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73933127332 for ; Tue, 6 Nov 2018 18:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 (1024-bit key) header.d=microsoft.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 gDzKn0O-FNnq for ; Tue, 6 Nov 2018 18:51:14 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0104.outbound.protection.outlook.com [104.47.53.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2A0126CB6 for ; Tue, 6 Nov 2018 18:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=opzsyyPDFlg45vzFoPX9Q5sKQI3y0WQSuE0EBmv3UAA=; b=SaKEBFceYRAPowG2bzWUHFIhXIImYZdb2plbAAKbKw/XBzHSd1D7FpRIBaekaOAcSHE6GYnCbRMiEomQmusSQu/crSsgVJXgzdxmb4N2cJRtU/wTK1BgLc7DXLQ9MRUYb5AKi0MRfhFOJ236BLMZIP7dB6kgeDSGKkCuDRac6fY= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0385.namprd00.prod.outlook.com (52.132.20.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1354.0; Wed, 7 Nov 2018 02:51:05 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::9968:f76e:fc46:f96]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::9968:f76e:fc46:f96%7]) with mapi id 15.20.1357.000; Wed, 7 Nov 2018 02:51:05 +0000 From: Mike Jones To: "id-event@ietf.org" Thread-Topic: Please use "identified with" language in subject type descriptions Thread-Index: AdR2Q7dpvUE5SGJhSz65voLV2VkxEg== Date: Wed, 7 Nov 2018 02:51:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:876:83ab:78c8:7c2d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0385; 6:UDTxX2gILx1Bi2YejwZ/dc+PYgyrMJgCCZ1g3htuP6wrGIwJMLT13+6scf4xFDioPl3m7fXUx6wxqFfhTUZRDXsSNVe8R2YDK+W1Qf2gwgWcdKv1fsnGcaisIysSxYdzh4WGRKhP03iyTUwNLaSNxGX7GuRbmwpeg2JJ7R2i398kYxopWtVGwalvzfdeIvOaTcVAwWd3NnKm2RXcBD+LuwlQTcOmynnPrzp+rPokgOvRuWvHtXLsvzrobeBV7ZGwyy9AEo9TFNv1Zvrb/kTj+W1JD2MxcowEsAp/T4+wubW3g0DPOEY89N2RsCpZJ30rMjVvm3uHwssw9SvCFMeUXN+VpvNvqjlmExj6zXaKlqnkOrPIsffCUgUWIxhQ3mhhrXaeLwpHrq40/e8atEV9q6fSJmJm5ai22wWFPZDveF8yLZt670Zjt+ck7OIp3hTuaIDYivn/B/BPCjBXkqMpHQ==; 5:Q3zaHsDbZyEHyb+Ed8jeFp0BuPgfzzIY/CqFEhWeO6fh1KuKh5w7xulnSCzxmiqseS7pzMFx7Mjtg/wjaOyMgcs+Ag3yrw5q3meCm7nphjW5/Nn7MUPkWC0/zK4+wFVT6gF7C8zXnCAaJA6Y8hw0okmqWosZT+BcsdQh3ftdJis=; 7:dUUfZ3yYOaGfUZU4sNDTYN7wC29CVcIh4XwjkTnUJ5JiVe3DdXMd+K1LA1iv+67RFByzowfu7yvP8CdmOtxvQ3TcDgqtf8f1+cuOjLCnJ82uoNmyJCLdf08dKJ8MAHeAV2PDQ4Unln2PnWtHg6XZCw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 63447137-1269-4724-75e4-08d6445bdca0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR00MB0385; x-ms-traffictypediagnostic: BL0PR00MB0385: x-ms-exchange-purlcount: 4 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220035)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(93006095)(93001095)(10201501046)(3231382)(944501410)(2018427008)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BL0PR00MB0385; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0385; x-forefront-prvs: 08497C3D99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(346002)(39860400002)(366004)(396003)(199004)(189003)(71200400001)(2351001)(14454004)(966005)(8676002)(81166006)(256004)(6116002)(105586002)(33656002)(72206003)(14444005)(81156014)(606006)(97736004)(8936002)(106356001)(99286004)(8990500004)(7696005)(6506007)(186003)(102836004)(10090500001)(476003)(71190400001)(486006)(790700001)(236005)(46003)(9686003)(54896002)(6306002)(53936002)(25786009)(7736002)(22452003)(6916009)(316002)(86612001)(2501003)(6436002)(86362001)(74316002)(5640700003)(68736007)(55016002)(2900100001)(2906002)(478600001)(10290500003)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0385; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: QPMSFocCJGsO7ebmu0d6bPkAeDPBvMzFICa+/PDlsrSBIV2BoW50ghrBNA6PfCfNXItZgyATPt+Tp3PZAlsxGH2Zgr1V7hGE0MHNYDbx9h64ixiYqQd60NMM590N8/fHiEDHl/+e3egHCyBN0+8PvmNbUtgyhAHe9t8ukqmcLCTCzoK+wy/mj45jfrVEISxdq5sZMN6yI+gR9glp+bm8lAUtGzGcygI5WQfctuBBHhOgcvzbO8KrBcQMGsso/DJu+E9PMTBHjrz7q1RPFwSF0YtGf732aSRu3P8ccB0aEhHHj50N+oIiKjcvm3LAUeTsXh0HtAaGRTxjpeRVZAhx34ktqXK532vcFUVlaZVFWAo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292A6710C176D4AEC8600D8F5C40BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 63447137-1269-4724-75e4-08d6445bdca0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 02:51:05.2569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0385 Archived-At: Subject: [Id-event] Please use "identified with" language in subject type descriptions X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 02:51:18 -0000 --_000_BL0PR00MB0292A6710C176D4AEC8600D8F5C40BL0PR00MB0292namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the draft-ietf-secevent-subject-identifiers subject identifier type defi= nitions, please use language along the lines of: Xyz: An xyz identified with the specified value. For instance: acct: "An account identified with the specified RFC 7565 account identifier= , omitting the "acct:" prefix". A precedent for this language is in the JWT "aud" (audience) claim definiti= on at https://tools.ietf.org/html/rfc7519#section-4.1.3, which says: If the principal processing the claim does not identify itself with a value= in the "aud" claim when this claim is present, then the JWT MUST be reject= ed. Thanks, -- Mike --_000_BL0PR00MB0292A6710C176D4AEC8600D8F5C40BL0PR00MB0292namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the draft-ietf-secevent-subject-identifiers subje= ct identifier type definitions, please use language along the lines of:

 

Xyz: An xyz identified= with the specified value.

 

For instance:

 

acct: “An account i= dentified with the specified RFC 7565 account identifier, omitting the R= 20;acct:” prefix”.

 

A precedent for this language is in the JWT “a= ud” (audience) claim definition at https://tools= .ietf.org/html/rfc7519#section-4.1.3, which says:

 

If the principal processi= ng the claim does not identify itself with a value in the "aud" c= laim when this claim is present, then the JWT MUST be rejected.<= /p>

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

--_000_BL0PR00MB0292A6710C176D4AEC8600D8F5C40BL0PR00MB0292namp_-- From nobody Thu Nov 8 02:07:55 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F881128C65 for ; Thu, 8 Nov 2018 02:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQzPci5N63WE for ; Thu, 8 Nov 2018 02:07:52 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 C3C90123FFD for ; Thu, 8 Nov 2018 02:07:51 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id q6-v6so13712503lfh.9 for ; Thu, 08 Nov 2018 02:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=r/BBHUig+MKnoMjXQxTcb/MOZ/sLAwoR0PjTRq0UFMo=; b=reyFXAJYKhL8X5zek6s/okRPIS6wtxVw43AGyxeEgKIgQjg3uukx7RtavLZv6UCjuf mje0/FDCP8DKd0DfnnJ+ty274CrP+/3EpPiGPUQiQj6NE8b9csRnZ3fTgjaY09AIAMb4 2Vs3r1fou2PaR+V0fvS0p3Sa2W56oPmPisOYKNEfv6zBANojPWPKVogpzzwSemBOneGn KRrwfS+N68K/PLGLKVsAvHfFQl06j6f54nJCi791wljVZVG178AF2Q89qxinzJG6koce tfextL/Qb2UuifljZGmQsYF7rVhswyIp0vCfhCE9eDzPm8/al8cIlV8Q8eF2kNrWe51y eFVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r/BBHUig+MKnoMjXQxTcb/MOZ/sLAwoR0PjTRq0UFMo=; b=dc1CkCkfzUnhdE6eRIuS6ut/gbKxOU/tBsdhS0lJ3H9ETAWf7L4CwVQBiZtZGxVkBj c+45XWTqTP3f/DSTGGtsfEjLWzQGQZ7h/X3rd1rIXmiA7yBYM0RRO6zTSFcF9/2OYWbu gmigUwbSmTgnrzpQYp5UePB9AWRC6ZOuQwcH6slkHEBGGIHz915pFy/7yxE53LBAbcmf 4q2dBRTaaRYfvZ0VNRPhgeDDKfmmVhDhqD8D5uFRyWafo8GtEzFMYNWNmVjgpJsPjqJX b1sfoa1MDRlWyTxk27cRA2/Pk3v6DdGMPTtuuhNRKHNyJCVPU/1sUgKllekwuEFjn7NS nwEg== X-Gm-Message-State: AGRZ1gLKR8ob85BI/ssDxiIN92R66ANLkg5WN4XCpbXH5YwMmnv+Ui79 hLhIpND52RmIF+6m/iDRhOm1QilryhxNYKiZE+G1+9Jj X-Google-Smtp-Source: AJdET5d96mh5H2Z5zjuBNQoK17bbpKgUVPVX+FvMYiXSMi94qOamspsX6UxAuLMC8FQAHKk0Rxgnaa8C4pL2Vt4VvkY= X-Received: by 2002:a19:ec09:: with SMTP id b9mr2442439lfa.65.1541671669521; Thu, 08 Nov 2018 02:07:49 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Thu, 8 Nov 2018 17:07:38 +0700 Message-ID: To: SecEvent Content-Type: multipart/alternative; boundary="00000000000038e2e8057a246830" Archived-At: Subject: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 10:07:54 -0000 --00000000000038e2e8057a246830 Content-Type: text/plain; charset="UTF-8" Many email providers will treat the following email addresses as equivalent: johnsmith@example.com JOHNSMITH@EXAMPLE.COM JohnSmith@example.com john.smith@example.com This has led users to view these strings as equivalent, and has led to email address canonicalization algorithms that are implementations specific, so that user entered email addresses resolve to the same canonical string. When receiving an email identifier, the recipient should use their implementation's canonicalization algorithm to resolve to the same subject identifier string used in their system. --00000000000038e2e8057a246830 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Many email providers will treat the following ema= il addresses as equivalent:


This has led users to view these strings as equivalent, and has led = to email address canonicalization algorithms that are implementations speci= fic, so that user entered email addresses resolve to the same canonical str= ing.=C2=A0 When receiving an email identifier, the recipient should use the= ir implementation's canonicalization algorithm to resolve to the same s= ubject identifier string used in their system.




--00000000000038e2e8057a246830-- From nobody Thu Nov 8 02:27:17 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1BE130E2E for ; Thu, 8 Nov 2018 02:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oF34DnIHHYJI for ; Thu, 8 Nov 2018 02:27:09 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 D182712D7EA for ; Thu, 8 Nov 2018 02:27:08 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id v68-v6so5530711pfk.0 for ; Thu, 08 Nov 2018 02:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=nlI6i51yF0lVLsEGM58wmn+q2c3mXnxTO0VTnC2R62A=; b=n/xm4AsISBzRy2wZZQ91huEtHLMFDYIZLhzGiuMlEvqAPT8ExJwJlmYVU7TWYs1/H7 V4chsQl59bu6B6Asxqo0dMql5+tQjbSzk2sILzdQuxAdg9NpT2GQFVspgu9BJx1afP63 +v/Xq10ldL0q2hXmw995ZV0BxvlHk7Airo4oov7Gvq8OyfNNOUOh04yh66yiq2UlvI9X mK/MciGAOppaSAxo0rRpSHj1K/pXQr/2Da8ea8TGokHyqv3jtp89S6bc/jeJ2xTLT631 J0baiCUXVAwQKM6F3T9vzONmtgd/r8hqpimc1l4VKm9p1g9yEWFJ2wKtCJEaMV+KE6t0 LFUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nlI6i51yF0lVLsEGM58wmn+q2c3mXnxTO0VTnC2R62A=; b=LKuRjwvbDFrm5iKjCMCSS3nUMLkpO2hjGvJ3KAqb1BknUVy/z7V1U4InRd5qBYweL2 cEAzzUmpaZT7U/COhuLQyLnOLIjnpkHcHGYxnfUbCcy3zs97YojMaMmI4KMYUVizLwTl uZjCD165XxIMHY6th3H16YRdIl3GY9fSVKN30I3CnGdGd9vRuVKga3jWsfVhnz1HeKWV V1oGCxcyHksuVHGGFZN035fLCDwWitUQs3sircJOGcajqxEOaHSgZyGQjTJmYEWM4gZt okJCc45JtMxgUpfnofFpQYQirhJCqRSIJZVnuFd/yDgAt09oTEJFmY9t1wY2sR2KF85/ 0SeQ== X-Gm-Message-State: AGRZ1gJt7slUtg6f/QiSmCowcvtumuKzODC92sO+twaYEcOIHrqyFDEK RyD4OfBgczslxlanXoPMBOHV4msrxiY= X-Google-Smtp-Source: AJdET5c4F3MkgIGxnSCoboj475zE9VwCEzTdwdC91GJYWezgYFXivnq6KdGEpNNvV+dKXzAHjMaOEw== X-Received: by 2002:a62:1fca:: with SMTP id l71-v6mr4101992pfj.23.1541672828078; Thu, 08 Nov 2018 02:27:08 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:3525:415a:7442:d159? ([2001:67c:1232:144:3525:415a:7442:d159]) by smtp.gmail.com with ESMTPSA id x13-v6sm7706922pge.13.2018.11.08.02.27.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 02:27:07 -0800 (PST) To: Dick Hardt , SecEvent References: From: Yaron Sheffer Message-ID: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> Date: Thu, 8 Nov 2018 17:27:04 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 10:27:12 -0000 Looks good, and I think this is a normative SHOULD. Thanks, Yaron On 08/11/2018 17:07, Dick Hardt wrote: > > Many email providers will treat the following email addresses as equivalent: > > johnsmith@example.com > JOHNSMITH@EXAMPLE.COM > JohnSmith@example.com > john.smith@example.com > > This has led users to view these strings as equivalent, and has led to > email address canonicalization algorithms that are implementations > specific, so that user entered email addresses resolve to the same > canonical string.  When receiving an email identifier, the recipient > should use their implementation's canonicalization algorithm to resolve > to the same subject identifier string used in their system. > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > From nobody Thu Nov 8 02:29:02 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451B1128CB7 for ; Thu, 8 Nov 2018 02:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 zcW6rYRqZnBG for ; Thu, 8 Nov 2018 02:28:59 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 186C712008A for ; Thu, 8 Nov 2018 02:28:59 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id q186-v6so17498398ljb.5 for ; Thu, 08 Nov 2018 02:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JzijW3sjaveaSrupS1fujNrNGQZ3+eGaDKtkFL3U5NA=; b=ehJzcwScDpnQk7cEwcG5sDU2DhbFDpggThvg0oRf8z575eb2gBcmlv+DNqfu8dx3MJ W0ml4pu4SYrPG5oW75pTx05z1bylv1kHYOwd9n5SdH2JprqemhVyGGo0XdMjjCKqx2sb NVgduyUa+Wm856WsfJoEdEtoy3HGtRFM5A+KdwIdsdejIQaok/uuaKU3uGh4+vhDLsY8 b2UwmwGzeXJRR8oFzaGZY2aCdkxFYOIW6Me3obJM4RWa0W+tNslB0lbQNqgRDwld0+dp qPeSe4KWhQV2GnSN/IgKDrwR89qWAegNwoYOxHFz9QiJQJbBSi90doKJg2LspjR8JvsZ w7FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JzijW3sjaveaSrupS1fujNrNGQZ3+eGaDKtkFL3U5NA=; b=gFD4QanrC6oluumUzYKx0BgSg/JTZjb8L1YWiv+QUpo0X8adI9yjYt4vW77LAvdEQV XtaMhnhOZDmxX2BQADFp3/hF8GPX5V49b3USuMo8WKOM/LicvPY8sCdyG6Ptpv/tovMb 9G7S+4LJfp6Ses3ExxtD/01+5cD2+1AcaYKpOjRE/wFnfaBqzzPA7dTCHnuYymI/RkBA Mx84YXKKtCZXRQeAFwdkGYcBmew/CAREjI7cfNds5elg7oRuSOSBvx5msWqPqDPHmEFX QGOcP2NtGfWJMPlHbalyFp6q/ap4WLoTfRbINMu0Ry03OUikEc3tzlSvGCt+4SmZ/wtD zxsA== X-Gm-Message-State: AGRZ1gK4d50KuaIjvoCqO5oHYtfOnBPb61z5zTksPeS6/KtcHUYtlE7i eWgbvi1g0rK1Zs4dzSiU/3Nq6ntLk8ydq0oBRq7gIZg2 X-Google-Smtp-Source: AJdET5dQJ5iplsiEbme03BOzbwUKmUMk2NWaC3ADOXfOcIyUzX4/MvjoSsWhO2r9BxOeK70+F/baNSkO9+PTpzHmVE0= X-Received: by 2002:a2e:9059:: with SMTP id n25-v6mr2504393ljg.155.1541672936931; Thu, 08 Nov 2018 02:28:56 -0800 (PST) MIME-Version: 1.0 References: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> In-Reply-To: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> From: Dick Hardt Date: Thu, 8 Nov 2018 17:28:46 +0700 Message-ID: To: Yaron Sheffer Cc: SecEvent Content-Type: multipart/alternative; boundary="000000000000c404fe057a24b396" Archived-At: Subject: Re: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 10:29:01 -0000 --000000000000c404fe057a24b396 Content-Type: text/plain; charset="UTF-8" Agreed. On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer wrote: > Looks good, and I think this is a normative SHOULD. > > Thanks, > Yaron > > On 08/11/2018 17:07, Dick Hardt wrote: > > > > Many email providers will treat the following email addresses as > equivalent: > > > > johnsmith@example.com > > JOHNSMITH@EXAMPLE.COM > > JohnSmith@example.com > > john.smith@example.com > > > > This has led users to view these strings as equivalent, and has led to > > email address canonicalization algorithms that are implementations > > specific, so that user entered email addresses resolve to the same > > canonical string. When receiving an email identifier, the recipient > > should use their implementation's canonicalization algorithm to resolve > > to the same subject identifier string used in their system. > > > > > > > > > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > --000000000000c404fe057a24b396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed.

On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Looks good, and I think this is a normative SHOULD.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 08/11/2018 17:07, Dick Hardt wrote:
>
> Many email providers will treat the following email addresses as equiv= alent:
>
> johnsmith@e= xample.com <mailto:johnsmith@example.com>
> JOHNSMITH@E= XAMPLE.COM <mailto:JOHNSMITH@EXAMPLE.COM>
> JohnSmith@e= xample.com <mailto:JohnSmith@example.com>
> john.smith= @example.com <mailto:john.smith@example.com>
>
> This has led users to view these strings as equivalent, and has led to=
> email address canonicalization algorithms that are implementations > specific, so that user entered email addresses resolve to the same > canonical string.=C2=A0 When receiving an email identifier, the recipi= ent
> should use their implementation's canonicalization algorithm to re= solve
> to the same subject identifier string used in their system.
>
>
>
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/id-event
>
--000000000000c404fe057a24b396-- From nobody Thu Nov 8 13:53:04 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCAA1310C1 for ; Thu, 8 Nov 2018 13:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 M-NSpT6T09GM for ; Thu, 8 Nov 2018 13:52:49 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 3C244130FDC for ; Thu, 8 Nov 2018 13:52:49 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id n126so4725891vke.12 for ; Thu, 08 Nov 2018 13:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PW30lUzHRBDV4SjpI3pIBkPe3gfKg2hbZdEFRQKIusU=; b=DVKGerB24+HA2alfQ4cH1Etbms3b+2ZeqxsOkPFJjMxJk08Tqd6FBmx/7NO1sfHwJy ryXUjh1Mw4rc5XSpaY4XxoEWMa7hk05JfDYD1WbuMjom2kaLkaqzUeu+IMVgoyK7LVWT NQ9X51hnAvwjkQ44CaEZGLW5yLE5QxhQGC+pHE3vpybV7OdPBlrvdmTK3v5X3kdk3K++ +gtB4SLSCCWricZKw9rtuEieQPPVOKGus1u00RN1xRbXRjQcOs9PF7i0AnmVb0xCBYuy Dq+l0ffY4QucJsqE4lclbqxBspQ4JGSVkMbbcjIlRwuI1QkF2BU2EUmuNe02fT4tCSDv i4jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PW30lUzHRBDV4SjpI3pIBkPe3gfKg2hbZdEFRQKIusU=; b=QwIaXyWHNYKEon8DPVXrz7038BJRiT1sBdaCLVlK4+sen3BbRZY228twlsjtmc3SJV IqqXP+zbqS/do22l/7D+jAVZVGMrumHYggwGDA8A4pWfwrSKJi2gXaO/pWUDG+x2amYl xi5RpH9O/EBN4XkOz9AkqCUOshKvoHcr0+iP9gQhxBcmTb2taZT7VQJug0mh2BbYP5In yqVj2ly7bjdT1eJWC2Y2NfqGuTASW2tLIwNchExwS8LHmVOwBJyWRVWAeSdSRs/YSAMd viAvc8dYPOPqSqLXuuin5HJnqRxSlgUbO88w/po/PGI/uVrE0sxxvXB68V0mx/VS9Zix 4unQ== X-Gm-Message-State: AGRZ1gJ7yahiK9TsGAJuZEzfqE2WCAjQwaAxR+cs1Yd7HhMIM1S89H04 NtCykU83wfi1pTxpHa/Ndd+f3Tezh87VDU2I0AhunQ== X-Google-Smtp-Source: AJdET5ect/lk1yK6mHtHI9xkTHCfTpnegncsM0DJDeNXVI9UwJGynP3GIKq1CGA7+7TU32JDNaMGzAxFrHGdHq6KAWg= X-Received: by 2002:a1f:fcc3:: with SMTP id a186mr2962564vki.0.1541713967870; Thu, 08 Nov 2018 13:52:47 -0800 (PST) MIME-Version: 1.0 References: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> In-Reply-To: From: Adam Dawes Date: Thu, 8 Nov 2018 13:52:34 -0800 Message-ID: To: Dick Hardt Cc: Yaron Sheffer , ID Events Mailing List Content-Type: multipart/alternative; boundary="000000000000674162057a2e4199" Archived-At: Subject: Re: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 21:52:59 -0000 --000000000000674162057a2e4199 Content-Type: text/plain; charset="UTF-8" I think this makes sense. However, I wanted to point out that there's a higher level problem in that the Transmitter is providing it's canonicalized identifier in the SET and this may not map to the receiver's canonicalized identifier. For example, Alice may have registered alice.smith@mailprovider.com with merchantfoo.com. When mailprovider.com sends a SET to merchantfoo.com, it could be for alicesmith@mailprovider.com merchantfoo can't effectively remap the event to the proper account on their side without first knowing mailprovider.com's canonicalization scheme. I'm not sure what can be done about this absent some way for mailprovider.com to advertise its canonicalization scheme. Is there a suggestion to do that? On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt wrote: > Agreed. > > On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer > wrote: > >> Looks good, and I think this is a normative SHOULD. >> >> Thanks, >> Yaron >> >> On 08/11/2018 17:07, Dick Hardt wrote: >> > >> > Many email providers will treat the following email addresses as >> equivalent: >> > >> > johnsmith@example.com >> > JOHNSMITH@EXAMPLE.COM >> > JohnSmith@example.com >> > john.smith@example.com >> > >> > This has led users to view these strings as equivalent, and has led to >> > email address canonicalization algorithms that are implementations >> > specific, so that user entered email addresses resolve to the same >> > canonical string. When receiving an email identifier, the recipient >> > should use their implementation's canonicalization algorithm to resolve >> > to the same subject identifier string used in their system. >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Id-event mailing list >> > Id-event@ietf.org >> > https://www.ietf.org/mailman/listinfo/id-event >> > >> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > -- Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 --000000000000674162057a2e4199 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this makes sense. However, I wanted to point out t= hat there's a higher level problem in that the Transmitter is providing= it's canonicalized identifier in the SET and this may not map to the r= eceiver's canonicalized identifier.=C2=A0


merchantfoo can't effe= ctively remap the event to the proper account on their side without first k= nowing mailprovider.com's canon= icalization scheme. I'm not sure what can be done about this absent som= e way for mailprovider.com to adver= tise its canonicalization scheme. Is there a suggestion to do that?

On Thu, Nov 8, 2018 at = 2:29 AM Dick Hardt <dick.hardt@g= mail.com> wrote:
Agreed.

On Thu, = Nov 8, 2018 at 5:27 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Looks good, and I think this is a normative SHOU= LD.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 08/11/2018 17:07, Dick Hardt wrote:
>
> Many email providers will treat the following email addresses as equiv= alent:
>
> johnsmith@e= xample.com <mailto:johnsmith@example.com>
> JOHNSMITH@E= XAMPLE.COM <mailto:JOHNSMITH@EXAMPLE.COM>
> JohnSmith@e= xample.com <mailto:JohnSmith@example.com>
> john.smith= @example.com <mailto:john.smith@example.com>
>
> This has led users to view these strings as equivalent, and has led to=
> email address canonicalization algorithms that are implementations > specific, so that user entered email addresses resolve to the same > canonical string.=C2=A0 When receiving an email identifier, the recipi= ent
> should use their implementation's canonicalization algorithm to re= solve
> to the same subject identifier string used in their system.
>
>
>
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/id-event
>
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--
Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410

--000000000000674162057a2e4199-- From nobody Thu Nov 8 16:40:50 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4538E126F72 for ; Thu, 8 Nov 2018 16:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DQ1v2pM-LEz for ; Thu, 8 Nov 2018 16:40:47 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 E5509129C6A for ; Thu, 8 Nov 2018 16:40:46 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id e5-v6so137096lja.4 for ; Thu, 08 Nov 2018 16:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sumdKbFtEdlqnorvgKV4jOPp+WnskN6RoOGgDATOQg0=; b=QYedbh4iJ1gh5nLebEI41eyMzRiTdB+6O2VYypCbVchsNXXjFJ0uenuhF2EIAFR0PY JbPH00ksqG6keZFuiDS6kmVA6nMPNaANhSAoVcZzPptslYp9l2eP73WJZa4GCfzRuhsR PvckhSfbZnN9eGe1L7LIXeP5LLQlnURl+oR6B6TPUym3T23zoPygROuzebwETS6pIaPI y6DKpDVb+et8+i7VE1Oe5KLW3ondjk2zloml3VOTp3IGvYOybhTGM0EP4l4siWr21ACD zyQJycvOmGUw52NWDG6df6B6vhCaSUomUnJ2ByazlS2Adg+nQF7rS47bDM22VcgV/QDx CMUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sumdKbFtEdlqnorvgKV4jOPp+WnskN6RoOGgDATOQg0=; b=FjfPfTuS1lkTdbiiGn4fwu/iDcjq6yJuE3BdhJ5F/VInL3bUHBqMvz4SmrSRyAPYs/ 4wdAoovDs3Ygmmx7pojyfZ1ghh7Hv6BHkDiswkVXGO0b9fkH/pWjk6x/ET3HO2XroyRb Np+D3pnYkROTA0Pr6CXMsfMKyU1eD/fY8yhx0SwfWcK+ODVYdZwlYjViX+NzVeZ9+nd6 8dFnfcJc27USkCzrLe9M4TthnCvqd90rslWXSWZtuEf2d9noG6cf+kOXtjalRy7GPJq7 wOJKWlOJIdktm687JbOp1RYvbWJW/D9VzyF2Buu0A8srucVmPkJi/1xXVbDIAWk0nQMn 3Pyg== X-Gm-Message-State: AGRZ1gLJb4IzkKSGHI5fSFKJDRX+3bDEQBJC/kFoPbbxF13JwhKw/MM5 Zm+RB3uEuMboEe5ByxQQfkSA35jPBq2wDT/n69g= X-Google-Smtp-Source: AJdET5czFzHCVJqdPu47+5MQ9oJttkUkNmsu2enXtlnfxspJXHvIOnpfepcmSTPSJC+Mn566umX2kRWo3pMNgjJrU6c= X-Received: by 2002:a2e:9ec5:: with SMTP id h5-v6mr1619750ljk.40.1541724044884; Thu, 08 Nov 2018 16:40:44 -0800 (PST) MIME-Version: 1.0 References: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> In-Reply-To: From: Dick Hardt Date: Fri, 9 Nov 2018 07:40:31 +0700 Message-ID: To: Adam Dawes Cc: Yaron Sheffer , SecEvent Content-Type: multipart/alternative; boundary="0000000000000981e5057a309a76" Archived-At: Subject: Re: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 00:40:49 -0000 --0000000000000981e5057a309a76 Content-Type: text/plain; charset="UTF-8" Hey Adam The problem you are describing is what I was attempting to capture. Since Alice mailprovider.com removes dots, merchantfoo.com likely has already figured out mailprover.com's canonicalization since Alice can enter alice.smith@mailprovider.com or alicesmith@mailprovider.com at any site and receive email. The suggested text says merchantfoo.com SHOULD do the same canonicalization for email subject identifiers that it already does with emails entered by the user. Does that make sense? Suggested changes to the text? On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes wrote: > I think this makes sense. However, I wanted to point out that there's a > higher level problem in that the Transmitter is providing it's > canonicalized identifier in the SET and this may not map to the receiver's > canonicalized identifier. > > For example, Alice may have registered alice.smith@mailprovider.com with > merchantfoo.com. When mailprovider.com sends a SET to merchantfoo.com, it > could be for alicesmith@mailprovider.com > > merchantfoo can't effectively remap the event to the proper account on > their side without first knowing mailprovider.com's canonicalization > scheme. I'm not sure what can be done about this absent some way for > mailprovider.com to advertise its canonicalization scheme. Is there a > suggestion to do that? > > On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt wrote: > >> Agreed. >> >> On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer >> wrote: >> >>> Looks good, and I think this is a normative SHOULD. >>> >>> Thanks, >>> Yaron >>> >>> On 08/11/2018 17:07, Dick Hardt wrote: >>> > >>> > Many email providers will treat the following email addresses as >>> equivalent: >>> > >>> > johnsmith@example.com >>> > JOHNSMITH@EXAMPLE.COM >>> > JohnSmith@example.com >>> > john.smith@example.com >>> > >>> > This has led users to view these strings as equivalent, and has led to >>> > email address canonicalization algorithms that are implementations >>> > specific, so that user entered email addresses resolve to the same >>> > canonical string. When receiving an email identifier, the recipient >>> > should use their implementation's canonicalization algorithm to >>> resolve >>> > to the same subject identifier string used in their system. >>> > >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Id-event mailing list >>> > Id-event@ietf.org >>> > https://www.ietf.org/mailman/listinfo/id-event >>> > >>> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > > > -- > Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 > > --0000000000000981e5057a309a76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Adam

The problem you are describing= is what I was attempting to capture. Since Alice mailprovider.com removes dots, merchantfoo.com likely has already figured out mailprover.com's canonicalization since Alice can e= nter=C2=A0alice.smith@mailprovider.com=C2=A0or=C2=A0alicesmith@mailprovider.com=C2=A0= at any site and receive email. The suggested text says merchantfoo.com SHOULD do the same canonicalization for = email subject identifiers that it already does with emails entered by the u= ser.

Does that make sense? Suggested changes to th= e text?


On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes <adawes@google.com> wrote:
I think this makes sense. However, I wanted= to point out that there's a higher level problem in that the Transmitt= er is providing it's canonicalized identifier in the SET and this may n= ot map to the receiver's canonicalized identifier.=C2=A0

=
For example, Alice may have registered alice.smith@mailprovider.com with merchantfoo.com. Whe= n mailprovider.com sends a SET to merch= antfoo.com, it could be for alicesmith@mailprovider.com

<= div>merchantfoo can't effectively remap the event to the proper account= on their side without first knowing mailprovider.com's canonicalization scheme. I'm= not sure what can be done about this absent some way for mailprovider.com to advertise its = canonicalization scheme. Is there a suggestion to do that?

<= div class=3D"gmail_quote">
On Thu, Nov 8, 2018 at 2:29 AM D= ick Hardt <dic= k.hardt@gmail.com> wrote:
Agreed.

On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
<= /div>
Looks good, and I think this is a norma= tive SHOULD.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 08/11/2018 17:07, Dick Hardt wrote:
>
> Many email providers will treat the following email addresses as equiv= alent:
>
> johnsmith@e= xample.com <mailto:johnsmith@example.com>
> JOHNSMITH@E= XAMPLE.COM <mailto:JOHNSMITH@EXAMPLE.COM>
> JohnSmith@e= xample.com <mailto:JohnSmith@example.com>
> john.smith= @example.com <mailto:john.smith@example.com>
>
> This has led users to view these strings as equivalent, and has led to=
> email address canonicalization algorithms that are implementations > specific, so that user entered email addresses resolve to the same > canonical string.=C2=A0 When receiving an email identifier, the recipi= ent
> should use their implementation's canonicalization algorithm to re= solve
> to the same subject identifier string used in their system.
>
>
>
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/id-event
>
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--
Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410

=
--0000000000000981e5057a309a76-- From nobody Fri Nov 9 10:51:01 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03097130DC4 for ; Fri, 9 Nov 2018 10:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 0NE9i4016-zo for ; Fri, 9 Nov 2018 10:50:58 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 AF5EF130DC3 for ; Fri, 9 Nov 2018 10:50:57 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id t17so1620119vsc.8 for ; Fri, 09 Nov 2018 10:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h3fxl+uoApaxTdVWK7PIQtlfh1lkL9DifSUrAGsEJHk=; b=QoZn9StOxfMl+ZwlKEqZc3Bym3zUxPEMeOiOtV21bWgqOAaGQ0qXJY1vxe6UxBvx72 mAto4Vwg14dQXbJSfQM9k3nA8ohrkhdnw/wN/qdx8e3CXDrz+Tbv0BDPfAddyQ5lHt+Z gfvLSCJV9/O3oS8IzuS+imtsIoWGsWqfWtHjf5rd4hNKwHp+ObTct3DSq/FjoASB7qRY 4ZXguvzE7JQTG7B7eshH70IxO18WF+Pzr/+Z0G29N0Bv8bCArqgXa/RGkjftUA6S2Y5g Vw0URoKUSmd10nepgftPQ5vV/v+tpON9gV8p6DFiDkUkCKwxKVFn9pWQOHa+BUXVPstp NvKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h3fxl+uoApaxTdVWK7PIQtlfh1lkL9DifSUrAGsEJHk=; b=uVFIaimVe63bEHeiYytJa6/DKwe9nX2pMO/q9/04Tc0X8UiNLFTuK2OQAt/INT5Rbx KHmyL0mxbclKubTxiIOMBqtoE06iklQfkGaq3BX4hXAFgglbUOj1wnzW8FTWlJ+43GNZ DGf1lpj4dxaI9YyzhK0q8LSUTqv2+rullPjn4NTgTxOZpJOZ721i/iQdxRMSMhmB0iGo pEI4vF/d2Wn+NfM5Iupl8NwvYlpnzrx4dwueqk5xPOycj6A807qxo7X5aMkByHujuXJT Hycu+itykmbKX24igkJlGP+lTUshRD50b1I+OuWcp0J8fMo1xiuZF/uD7sZhBwtg+RIa KcDg== X-Gm-Message-State: AGRZ1gI1asnyuStceYkI6OEzQ+srOSQy5I2v30yNJamKWnmH8RZyDiLh rDXkFsw4IOL8PhSE9+wbdM1t6ImVy2yLkTCNdAyZnw== X-Google-Smtp-Source: AJdET5ci7r6kPzKib+78DglqVYUxJ/gIgP82ucRNlZw2naSLofP+3MMZmNOla3L+QaZm+/iRgcRRPt68uiaOAOvEI5w= X-Received: by 2002:a67:1646:: with SMTP id 67mr4375142vsw.129.1541789456353; Fri, 09 Nov 2018 10:50:56 -0800 (PST) MIME-Version: 1.0 References: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> In-Reply-To: From: Adam Dawes Date: Fri, 9 Nov 2018 10:50:44 -0800 Message-ID: To: Dick Hardt Cc: Yaron Sheffer , ID Events Mailing List Content-Type: multipart/alternative; boundary="000000000000dde1c5057a3fd40c" Archived-At: Subject: Re: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 18:51:00 -0000 --000000000000dde1c5057a3fd40c Content-Type: text/plain; charset="UTF-8" I think it does make sense to do the same canonicalization for SETs. But I suspect that most canonicalization that apps do is purely focused on proper lower casing. I would be more surprised if apps canonicalize on special characters like .,+ etc. I don't know as if there are any guidance in the mail RFCs on how to treat these so I think there are inconsistent treatments from mail providers. Some apps may understand the conventions of larger mail providers but I suspect you're still going to have discrepancies that are hard to iron out without fully understanding the mail provider's canonicalization scheme. And some users expect that their mail will not be canoncialized. For example, Gmail provides the + character so that a user can give unique addresses to each recipient alice.smith+merchantfoo@mailprovider.com. If merchantfoo stripped the + in canonicalizing, then Alice wouldn't be able to manage mail from merchantfoo as easily. On Thu, Nov 8, 2018 at 4:40 PM Dick Hardt wrote: > Hey Adam > > The problem you are describing is what I was attempting to capture. Since > Alice mailprovider.com removes dots, merchantfoo.com likely has already > figured out mailprover.com's canonicalization since Alice can enter > alice.smith@mailprovider.com or alicesmith@mailprovider.com > at any site and receive email. The > suggested text says merchantfoo.com SHOULD do the same canonicalization > for email subject identifiers that it already does with emails entered by > the user. > > Does that make sense? Suggested changes to the text? > > > On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes wrote: > >> I think this makes sense. However, I wanted to point out that there's a >> higher level problem in that the Transmitter is providing it's >> canonicalized identifier in the SET and this may not map to the receiver's >> canonicalized identifier. >> >> For example, Alice may have registered alice.smith@mailprovider.com with >> merchantfoo.com. When mailprovider.com sends a SET to merchantfoo.com, >> it could be for alicesmith@mailprovider.com >> >> merchantfoo can't effectively remap the event to the proper account on >> their side without first knowing mailprovider.com's canonicalization >> scheme. I'm not sure what can be done about this absent some way for >> mailprovider.com to advertise its canonicalization scheme. Is there a >> suggestion to do that? >> >> On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt wrote: >> >>> Agreed. >>> >>> On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer >>> wrote: >>> >>>> Looks good, and I think this is a normative SHOULD. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 08/11/2018 17:07, Dick Hardt wrote: >>>> > >>>> > Many email providers will treat the following email addresses as >>>> equivalent: >>>> > >>>> > johnsmith@example.com >>>> > JOHNSMITH@EXAMPLE.COM >>>> > JohnSmith@example.com >>>> > john.smith@example.com >>>> > >>>> > This has led users to view these strings as equivalent, and has led >>>> to >>>> > email address canonicalization algorithms that are implementations >>>> > specific, so that user entered email addresses resolve to the same >>>> > canonical string. When receiving an email identifier, the recipient >>>> > should use their implementation's canonicalization algorithm to >>>> resolve >>>> > to the same subject identifier string used in their system. >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Id-event mailing list >>>> > Id-event@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/id-event >>>> > >>>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >> >> >> -- >> Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 >> >> -- Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 --000000000000dde1c5057a3fd40c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it does make sense to do the same canonicalization= for SETs. But I suspect that most canonicalization that apps do is purely = focused on proper lower casing. I would be more surprised if apps canonical= ize on special characters like .,+ etc. I don't know as if there are an= y guidance in the mail RFCs on how to treat these so I think there are inco= nsistent treatments from mail providers. Some apps may understand the conve= ntions of larger mail providers but I suspect you're still going to hav= e discrepancies that are hard to iron out without fully understanding the m= ail provider's canonicalization scheme. And some users expect that thei= r mail will not be canoncialized. For example, Gmail provides the=C2=A0+ ch= aracter so that a user can give unique addresses to each recipient alice.smith+merchant= foo@mailprovider.com. If merchantfoo stripped the=C2=A0+ in canonicaliz= ing, then Alice wouldn't be able to manage mail from merchantfoo as eas= ily.=C2=A0

On Thu, Nov= 8, 2018 at 4:40 PM Dick Hardt <= dick.hardt@gmail.com> wrote:
Hey Adam

The problem you are describin= g is what I was attempting to capture. Since Alice mailprovider.com removes dots, merchantfoo.com likely has a= lready figured out mail= prover.com's canonicalization since Alice can enter=C2=A0alice.smith@mailpro= vider.com=C2=A0or=C2=A0alicesmith@mailprovider.com=C2=A0at any site and rece= ive email. The suggested text says merchantfoo.com SHOULD do the same canonicalization for em= ail subject identifiers that it already does with emails entered by the use= r.

Does that make sense? Suggested changes to the = text?


On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes <adawes@google.com> wrote:
I think this makes sense. How= ever, I wanted to point out that there's a higher level problem in that= the Transmitter is providing it's canonicalized identifier in the SET = and this may not map to the receiver's canonicalized identifier.=C2=A0<= div>
For example, Alice may have registered alice.smith@mailprovider.c= om with merchantfo= o.com. When mailp= rovider.com sends a SET to merchantfoo.com, it could be for alicesmith@mailprovider.com

merchantfoo can't effectively remap the event to the = proper account on their side without first knowing mailprovider.com's canonicalization s= cheme. I'm not sure what can be done about this absent some way for mailprovider.com to = advertise its canonicalization scheme. Is there a suggestion to do that?

On Thu, Nov 8, 201= 8 at 2:29 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Agreed.

=
On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Looks good, and I thi= nk this is a normative SHOULD.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 08/11/2018 17:07, Dick Hardt wrote:
>
> Many email providers will treat the following email addresses as equiv= alent:
>
> johnsmith@e= xample.com <mailto:johnsmith@example.com>
> JOHNSMITH@E= XAMPLE.COM <mailto:JOHNSMITH@EXAMPLE.COM>
> JohnSmith@e= xample.com <mailto:JohnSmith@example.com>
> john.smith= @example.com <mailto:john.smith@example.com>
>
> This has led users to view these strings as equivalent, and has led to=
> email address canonicalization algorithms that are implementations > specific, so that user entered email addresses resolve to the same > canonical string.=C2=A0 When receiving an email identifier, the recipi= ent
> should use their implementation's canonicalization algorithm to re= solve
> to the same subject identifier string used in their system.
>
>
>
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/id-event
>
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--
Adam Dawe= s=C2=A0|=C2=A0Sr. Produ= ct Manager=C2=A0|=C2=A0adawes@google.com= =C2=A0|=C2=A0+1 650-214= -2410



--
Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410

--000000000000dde1c5057a3fd40c-- From nobody Fri Nov 9 11:29:28 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93252130F1B for ; Fri, 9 Nov 2018 11:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.781 X-Spam-Level: X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 CyO6-UzGjILH for ; Fri, 9 Nov 2018 11:29:16 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 16C5012426A for ; Fri, 9 Nov 2018 11:28:59 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA9JSjFJ058632; Fri, 9 Nov 2018 19:28:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=sDQJODwYSYSxiHMHDilmggFJGGlwV66JdAyTCvJNAL0=; b=ld18BqdElrV6ZehDQzTAap7hz04IKWkY3hnF6Kw8ZNVp/A3DkCQNOnPyO8XK758L6Ev/ kGkUgx6tiBz1tBCsNS9opOjQnlpISMjVQogtrKWii2klwP457aAryY+PjErx2QAylZBS CpXfrYyIXSaaj4AHT0d/cGSdfShOaTLKVfqJCDNTDDpMQXzoREt1uawhT95hvxc3X19m Cce5yoWGDb6xsNiVkaELTRy2djgQtS8N6IRxL4+8SwLLpxxMRP4iU/9CxCyvsYpuYetL GQgmW6evJzPHjXvAvsNeQbFxSBbyqSy/HX5wUGbVycxgFMQzyT9r1v/+wm7udWo+kXd4 9w== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2nh3mq8vgm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 09 Nov 2018 19:28:53 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA9JSq5k014163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Nov 2018 19:28:53 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wA9JSqJD029910; Fri, 9 Nov 2018 19:28:52 GMT Received: from [192.168.1.19] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Nov 2018 11:28:51 -0800 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DF6FFDF0-7B3A-4010-9822-06F4DDE7E785" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Fri, 9 Nov 2018 11:28:48 -0800 In-Reply-To: Cc: Dick Hardt , Yaron Sheffer , ID Events Mailing List To: Adam Dawes References: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> X-Mailer: Apple Mail (2.3445.101.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9072 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811090176 Archived-At: Subject: Re: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 19:29:26 -0000 --Apple-Mail=_DF6FFDF0-7B3A-4010-9822-06F4DDE7E785 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why is RFC5321 not sufficient to = define canonicalization for email addresses? Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Nov 9, 2018, at 10:50 AM, Adam Dawes = wrote: >=20 > I think it does make sense to do the same canonicalization for SETs. = But I suspect that most canonicalization that apps do is purely focused = on proper lower casing. I would be more surprised if apps canonicalize = on special characters like .,+ etc. I don't know as if there are any = guidance in the mail RFCs on how to treat these so I think there are = inconsistent treatments from mail providers. Some apps may understand = the conventions of larger mail providers but I suspect you're still = going to have discrepancies that are hard to iron out without fully = understanding the mail provider's canonicalization scheme. And some = users expect that their mail will not be canoncialized. For example, = Gmail provides the + character so that a user can give unique addresses = to each recipient alice.smith+merchantfoo@mailprovider.com = . If merchantfoo = stripped the + in canonicalizing, then Alice wouldn't be able to manage = mail from merchantfoo as easily.=20 >=20 > On Thu, Nov 8, 2018 at 4:40 PM Dick Hardt > wrote: > Hey Adam >=20 > The problem you are describing is what I was attempting to capture. = Since Alice mailprovider.com = removes dots, = merchantfoo.com = likely has = already figured out mailprover.com = 's = canonicalization since Alice can enter alice.smith@mailprovider.com = or alicesmith@mailprovider.com = at any site and receive email. The = suggested text says merchantfoo.com = SHOULD do the = same canonicalization for email subject identifiers that it already does = with emails entered by the user. >=20 > Does that make sense? Suggested changes to the text? >=20 >=20 > On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes > wrote: > I think this makes sense. However, I wanted to point out that there's = a higher level problem in that the Transmitter is providing it's = canonicalized identifier in the SET and this may not map to the = receiver's canonicalized identifier.=20 >=20 > For example, Alice may have registered alice.smith@mailprovider.com = with merchantfoo.com = . When = mailprovider.com = sends a SET to = merchantfoo.com = , it could be = for alicesmith@mailprovider.com >=20 > merchantfoo can't effectively remap the event to the proper account on = their side without first knowing mailprovider.com = 's = canonicalization scheme. I'm not sure what can be done about this absent = some way for mailprovider.com = to advertise = its canonicalization scheme. Is there a suggestion to do that? >=20 > On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt > wrote: > Agreed. >=20 > On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer > wrote: > Looks good, and I think this is a normative SHOULD. >=20 > Thanks, > Yaron >=20 > On 08/11/2018 17:07, Dick Hardt wrote: > >=20 > > Many email providers will treat the following email addresses as = equivalent: > >=20 > > johnsmith@example.com = > > > JOHNSMITH@EXAMPLE.COM = > > > JohnSmith@example.com = > > > john.smith@example.com = > > >=20 > > This has led users to view these strings as equivalent, and has led = to=20 > > email address canonicalization algorithms that are implementations=20= > > specific, so that user entered email addresses resolve to the same=20= > > canonical string. When receiving an email identifier, the recipient=20= > > should use their implementation's canonicalization algorithm to = resolve=20 > > to the same subject identifier string used in their system. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event = > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 >=20 > --=20 > Adam Dawes | Sr. Product Manager | adawes@google.com = | +1 650-214-2410 >=20 >=20 >=20 > --=20 > Adam Dawes | Sr. Product Manager | adawes@google.com = | +1 650-214-2410 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D3R8Gzz4c6jGa09Z= Hko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=3D4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW= 5U&e=3D = --Apple-Mail=_DF6FFDF0-7B3A-4010-9822-06F4DDE7E785 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Why = is RFC5321 not sufficient to define canonicalization = for email addresses?

Phil

Oracle Corporation, Cloud Security and = Identity Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Nov 9, 2018, at 10:50 AM, Adam Dawes <adawes=3D40google.com@dmarc.ietf.org> wrote:

I = think it does make sense to do the same canonicalization for SETs. But I = suspect that most canonicalization that apps do is purely focused on = proper lower casing. I would be more surprised if apps canonicalize on = special characters like .,+ etc. I don't know as if there are any = guidance in the mail RFCs on how to treat these so I think there are = inconsistent treatments from mail providers. Some apps may understand = the conventions of larger mail providers but I suspect you're still = going to have discrepancies that are hard to iron out without fully = understanding the mail provider's canonicalization scheme. And some = users expect that their mail will not be canoncialized. For example, = Gmail provides the + character so that a user can give unique = addresses to each recipient alice.smith+merchantfoo@mailprovider.com. If merchantfoo = stripped the + in canonicalizing, then Alice wouldn't be able to = manage mail from merchantfoo as easily. 

On Thu, Nov 8, 2018 at 4:40 PM Dick = Hardt <dick.hardt@gmail.com> wrote:
Hey Adam

The problem you are describing is what I was attempting to = capture. Since Alice mailprovider.com removes dots, merchantfoo.comlikely = has already figured out mailprover.com's = canonicalization since Alice can enter alice.smith@mailprovider.com or alicesmith@mailprovider.com at any site and receive = email. The suggested text says merchantfoo.com SHOULD do the same = canonicalization for email subject identifiers that it already does with = emails entered by the user.

Does that make sense? Suggested changes to the = text?


On Fri, Nov 9, 2018 at = 4:52 AM Adam Dawes <adawes@google.com> wrote:
I think this makes sense. However, I wanted to = point out that there's a higher level problem in that the Transmitter is = providing it's canonicalized identifier in the SET and this may not map = to the receiver's canonicalized identifier. 

For example, Alice may have = registered alice.smith@mailprovider.com with merchantfoo.com. = When mailprovider.com sends a SET to merchantfoo.com, it = could be for alicesmith@mailprovider.com

merchantfoo can't effectively remap the = event to the proper account on their side without first knowing mailprovider.com's = canonicalization scheme. I'm not sure what can be done about this absent = some way for mailprovider.com to advertise its = canonicalization scheme. Is there a suggestion to do = that?

On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Agreed.

On Thu, Nov 8, 2018 at = 5:27 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Looks good, = and I think this is a normative SHOULD.

Thanks,
        Yaron

On 08/11/2018 17:07, Dick Hardt wrote:
> 
> Many = email providers will treat the following email addresses as = equivalent:
> 
> johnsmith@example.com <mailto:johnsmith@example.com>
> JOHNSMITH@EXAMPLE.COM <mailto:JOHNSMITH@EXAMPLE.COM>
> JohnSmith@example.com <mailto:JohnSmith@example.com>
> john.smith@example.com <mailto:john.smith@example.com>
> 
> This = has led users to view these strings as equivalent, and has led to 
> email = address canonicalization algorithms that are implementations 
> = specific, so that user entered email addresses resolve to the same 
> = canonical string.  When receiving an email identifier, the = recipient 
> should use their implementation's canonicalization = algorithm to resolve > to the same subject identifier string used in their = system.
> 
> 
> 
> 
> 
> 
> = _______________________________________________
> = Id-event mailing list
> Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
> 
____________________________________________= ___
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


-- 
Adam Dawes | Sr. Product = Manager | adawes@google.com | +1= 650-214-2410



-- 
Adam Dawes | Sr. Product Manager | adawes@google.com | +1 = 650-214-2410

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3D3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=3D4a2fxkjOZS= ARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e=3D
= --Apple-Mail=_DF6FFDF0-7B3A-4010-9822-06F4DDE7E785-- From nobody Fri Nov 9 15:58:51 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5821128C65 for ; Fri, 9 Nov 2018 15:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 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, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 N1rftutZiUO3 for ; Fri, 9 Nov 2018 15:58:45 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 A94291277CC for ; Fri, 9 Nov 2018 15:58:44 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id t22-v6so3020976lji.7 for ; Fri, 09 Nov 2018 15:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i6fk//jXp7MPbMBR1HtLHR04DyYCFSNPfupzCxHbKz8=; b=APWn1VICEkRxjxjUpdBLSURhLUPVHvXMZF0hYr0eM7vsTLR7KXrPCyX7zj2Ek9iMKS xsBCuY568o6aOnWIFThIu4Dut73wjk+BfTyho+HezHVDB1yhaqjyl9USaw3umIICf+L3 HFBCilylFZUtcHHyNyFQ3dkRwGk2cNr/keMAPNNuqQwG59QxR471oyRWB6zISyIcq40O CcZ1Jmw27GTiiGuH8hcJj04Gdaz+raifMt8eDh0BivTqi+KPIR3jHnjsC6rS9NXsiX5N 8ggFR/97Pj8sFMDCcTM5rmAilH4T6FMynF6iDoEuatfFB6yQRUZboYnTeyia229TqlHl QSIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i6fk//jXp7MPbMBR1HtLHR04DyYCFSNPfupzCxHbKz8=; b=MpgyMZlpEmMcXfzqIhghs3Z/VyqVvrsbhdZq/hgIJQyt8Nts4qYenIN9CtqDQeC45e unH6vU9TrvIL5NS+HDqdV+K0adLn0Nmvg9Uouxz/epFBZemkt44C6FZl+gIVEJSZsPj5 PHDda7RFjrsiI7YXrloCqXQSOo7XV0tk//9NpqdPrBcLWBv7Q7zrY4S36ToD4fnpG3v2 2YgQAgpXeEUw753PcNstz+VbDwDbR+ZoEuuGnQ3coGeuaTpDVMECzysR8CNhn5SDSE3a JWZDWA7R2u5Yoz5tCOifx+H1n4brrgZ7Ov/FQUNfBM7/Kk0s2tmBGTR72YQwmwjXVB81 MjAw== X-Gm-Message-State: AGRZ1gIujo1LQQxLPYfIFoZ0Dj++tNYKNwEXvHPtIqtINCZWPs9u070n V0OxFD+uSyhnYEjHcko9nd2K4waYT3JDgXFFAdY= X-Google-Smtp-Source: AJdET5cQl+tQo2sfwQuOYfBH9MxIvY7T6bNJ7hpq8LcS+z4ivzu8VfeK0jQ/tnN2jHi9+CMcBZjemHLa13YniZLHFUM= X-Received: by 2002:a2e:478f:: with SMTP id u137-v6mr6851594lja.142.1541807922623; Fri, 09 Nov 2018 15:58:42 -0800 (PST) MIME-Version: 1.0 References: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> In-Reply-To: From: Dick Hardt Date: Sat, 10 Nov 2018 06:58:29 +0700 Message-ID: To: Phil Hunt Cc: Adam Dawes , Yaron Sheffer , SecEvent Content-Type: multipart/alternative; boundary="0000000000008a3d4f057a4421e3" Archived-At: Subject: Re: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 23:58:50 -0000 --0000000000008a3d4f057a4421e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Phil: RFC5321 describes a valid email address, it is not canonical. Adam: in my experience, we strip the dots in gmail addresses, since we have learned that is what Google does. :) As to the '+' functionality, some parties may use that to know it is the same subject at the host. For example, if merchantfoo subscribed to receive events for subject alicesmith+merchantfoo@mailprovider.com from mailprovider.com, then mailprovider.com would canonicalize the subject to alicesmith@mailprovider.com . While merchantfoo would use alicesmith+merchantfoo@mailprovider.com for sending email, it would likely be useful for merchantfoo to know that alicesmith@mailprovider.com and alicesmith+merchantfoo@mailprovider.com are the same subject from a SET point of view. For example, if merchantfoo is attempting to find mutual subjects with a non-email provider, socialfoo.com, then they would ideally both use alicesmith@mailprovider.com even though Alice had provided alicesmith+merchantfoo@mailprovider.com to merchantfoor and alicesmith+socialfoo@mailprovider.com to socialfoo. In the WG meeting there was a discussion about standardizing canonicalization, and the consensus in the meeting was that was out of scope, but that it was important to call out the issue. On Sat, Nov 10, 2018 at 2:28 AM Phil Hunt wrote: > Why is RFC5321 not sufficient to > define canonicalization for email addresses? > > Phil > > Oracle Corporation, Cloud Security and Identity Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Nov 9, 2018, at 10:50 AM, Adam Dawes < > adawes=3D40google.com@dmarc.ietf.org> wrote: > > I think it does make sense to do the same canonicalization for SETs. But = I > suspect that most canonicalization that apps do is purely focused on prop= er > lower casing. I would be more surprised if apps canonicalize on special > characters like .,+ etc. I don't know as if there are any guidance in the > mail RFCs on how to treat these so I think there are inconsistent > treatments from mail providers. Some apps may understand the conventions = of > larger mail providers but I suspect you're still going to have > discrepancies that are hard to iron out without fully understanding the > mail provider's canonicalization scheme. And some users expect that their > mail will not be canoncialized. For example, Gmail provides the + charact= er > so that a user can give unique addresses to each recipient > alice.smith+merchantfoo@mailprovider.com. If merchantfoo stripped the + > in canonicalizing, then Alice wouldn't be able to manage mail from > merchantfoo as easily. > > On Thu, Nov 8, 2018 at 4:40 PM Dick Hardt wrote: > >> Hey Adam >> >> The problem you are describing is what I was attempting to capture. Sinc= e >> Alice mailprovider.com >> >> removes dots, merchantfoo.com >> likely >> has already figured out mailprover.com >> 's >> canonicalization since Alice can enter alice.smith@mailprovider.com or >> alicesmith@mailprovider.com at any site >> and receive email. The suggested text says merchantfoo.com >> >> SHOULD do the same canonicalization for email subject identifiers that >> it already does with emails entered by the user. >> >> Does that make sense? Suggested changes to the text? >> >> >> On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes wrote: >> >>> I think this makes sense. However, I wanted to point out that there's a >>> higher level problem in that the Transmitter is providing it's >>> canonicalized identifier in the SET and this may not map to the receive= r's >>> canonicalized identifier. >>> >>> For example, Alice may have registered alice.smith@mailprovider.com wit= h >>> merchantfoo.com >>> . >>> When mailprovider.com >>> >>> sends a SET to merchantfoo.com >>> , >>> it could be for alicesmith@mailprovider.com >>> >>> merchantfoo can't effectively remap the event to the proper account on >>> their side without first knowing mailprovider.com >>> 's >>> canonicalization scheme. I'm not sure what can be done about this absen= t >>> some way for mailprovider.com >>> >>> to advertise its canonicalization scheme. Is there a suggestion to do >>> that? >>> >>> On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt wrote: >>> >>>> Agreed. >>>> >>>> On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer >>>> wrote: >>>> >>>>> Looks good, and I think this is a normative SHOULD. >>>>> >>>>> Thanks, >>>>> Yaron >>>>> >>>>> On 08/11/2018 17:07, Dick Hardt wrote: >>>>> > >>>>> > Many email providers will treat the following email addresses as >>>>> equivalent: >>>>> > >>>>> > johnsmith@example.com >>>>> > JOHNSMITH@EXAMPLE.COM >>>>> > JohnSmith@example.com >>>>> > john.smith@example.com >>>>> > >>>>> > This has led users to view these strings as equivalent, and has led >>>>> to >>>>> > email address canonicalization algorithms that are implementations >>>>> > specific, so that user entered email addresses resolve to the same >>>>> > canonical string. When receiving an email identifier, the recipien= t >>>>> >>>>> > should use their implementation's canonicalization algorithm to >>>>> resolve >>>>> > to the same subject identifier string used in their system. >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Id-event mailing list >>>>> > Id-event@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> > >>>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>> >>> >>> -- >>> Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 >>> >>> > > -- > Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 > <+1%20650-214-2410> > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D3R8Gzz4c6jGa09ZH= ko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=3D4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U= &e=3D > > > --0000000000008a3d4f057a4421e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Phil:=C2=A0RFC5321=C2=A0describes a valid email address, it is = not canonical.=C2=A0

Adam: in my experience, we strip th= e dots in gmail addresses, since we have learned that is what Google does. = :)
As to the '+' functionality, some parties may use that= to know it is the same subject at the host. For example, if merchantfoo su= bscribed to receive events for subject=C2=A0alicesmith+merchantfoo@mailprovider.com=C2=A0from = mailprovider.com, then mailprovider.com would canonicalize the subject= to=C2=A0 =C2=A0alicesm= ith@mailprovider.com.

While merchantfoo would = use=C2=A0=C2=A0alicesmi= th+merchantfoo@mailprovider.com=C2=A0for sending email, it would likely= be useful for merchantfoo to know that=C2=A0=C2=A0alicesmith@mailprovider.com=C2=A0and=C2=A0 = =C2=A0alicesmith+merch= antfoo@mailprovider.com=C2=A0are the same subject from a SET point of v= iew. For example, if merchantfoo is attempting to find mutual subjects with= a non-email provider, socialfoo.com, = then they would ideally both use=C2=A0=C2=A0alicesmith@mailprovider.com=C2=A0even though Alice= had provided=C2=A0=C2=A0alicesmith+merchantfoo@mailprovider.com=C2=A0to merchantfoor and=C2= =A0=C2=A0alicesmith+soc= ialfoo@mailprovider.com=C2=A0to socialfoo.

In = the WG meeting there was a discussion about standardizing canonicalization,= and the consensus in the meeting was that was out of scope, but that it wa= s important to call out the issue.


=


On Sat, Nov 10, 2018 at 2:28 AM Phil Hunt <phil.hunt@oracle.com> wrote:
Why is=C2=A0RFC5321=C2=A0not sufficient to define canonicalization for ema= il addresses?

Phil

Oracle Corporation, Clo= ud Security and Identity Architect
@independentid
phil.hunt@oracle.com

On Nov 9, 2018, at 10:50 AM, Adam D= awes <adawes=3D40google.com@dmarc.ietf.org> wrote:

I think it does make sense to do the same canonicalization = for SETs. But I suspect that most canonicalization that apps do is purely f= ocused on proper lower casing. I would be more surprised if apps canonicali= ze on special characters like .,+ etc. I don't know as if there are any= guidance in the mail RFCs on how to treat these so I think there are incon= sistent treatments from mail providers. Some apps may understand the conven= tions of larger mail providers but I suspect you're still going to have= discrepancies that are hard to iron out without fully understanding the ma= il provider's canonicalization scheme. And some users expect that their= mail will not be canoncialized. For example, Gmail provides the=C2=A0+ cha= racter so that a user can give unique addresses to each recipient=C2=A0alice.s= mith+merchantfoo@mailprovider.com. If merchantfoo stripped the=C2=A0+ i= n canonicalizing, then Alice wouldn't be able to manage mail from merch= antfoo as easily.=C2=A0

On Thu, Nov 8, 2018 at 4:40 PM Dick Hardt= <dick.hardt@g= mail.com> wrote:
Hey Adam=

The problem you are describing is what I was attempting= to capture. Since Alice=C2=A0mailprovider.com= =C2=A0re= moves dots,=C2= =A0merchantfoo.comlikely has alr= eady figured out=C2=A0mailprover.com's canon= icalization since Alice can enter=C2=A0alice.smith@mailprovider.com=C2=A0or=C2= =A0alices= mith@mailprovider.com=C2=A0at any site and receive email. The suggested= text says=C2= =A0merchantfoo.com=C2=A0SHOULD do the sa= me canonicalization for email subject identifiers that it already does with= emails entered by the user.

Does that make sense?= Suggested changes to the text?


On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes &l= t;adawes@google.com<= /a>> wrote:
I think this make= s sense. However, I wanted to point out that there's a higher level pro= blem in that the Transmitter is providing it's canonicalized identifier= in the SET and this may not map to the receiver's canonicalized identi= fier.=C2=A0

For example, Alice may have registered=C2=A0alice.smith@mail= provider.com=C2=A0with=C2=A0merchantfoo.com. When=C2=A0mailprovider.com=C2=A0sends a SET to=C2=A0merchantfoo.com, it could be for=C2=A0alicesmith@mailprovider.com

merchantfoo can't effectively remap the event to = the proper account on their side without first knowing=C2=A0mailprovider.com's canonicalization scheme. I'm not= sure what can be done about this absent some way for=C2=A0mailprovider.com=C2=A0to advertise its canonicalization scheme. Is the= re a suggestion to do that?

On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt <dick.hardt@gmail.com> wrote= :
Agreed.

On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer= <yaronf.ietf= @gmail.com> wrote:
Looks good, and I thin= k this is a normative SHOULD.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Ya= ron

On 08/11/2018 17:07, Dick Hardt wrote:
>=C2=A0
> Many email = providers will treat the following email addresses as equivalent:
>=C2=A0
= >=C2=A0johnsmith@exam= ple.com=C2= =A0<mailto:johnsmith@example.com>
>=C2=A0JOHNSMITH@EXAMPLE.COM=C2=A0<mailto:JOHNSMITH@EXAMPLE.COM>
= >=C2=A0JohnSmith@exam= ple.com=C2= =A0<mailto:JohnSmith@example.com>
>=C2=A0john.smith@example.com=C2=A0<mailto:john.smith@example.com>=
>=C2=A0<= /span>
> This has led users to view these strings as equivalent, and = has led to=C2= =A0
> email address canonicalization algorithms that are imple= mentations=C2= =A0
> specific, so that user entered email addresses resolve t= o the same=C2= =A0
> canonical string.=C2=A0 When receiving an email identifi= er, the recipient=C2=A0
> should use their implementation's canonicalizat= ion algorithm to resolve=C2=A0
> to the same subject identifier string used i= n their system.
>=C2=A0
>=C2=A0
>=C2=A0
>=C2=A0
>=C2=A0
>=C2=A0
> _______________= ________________________________
> Id-event mailing list
>=C2=A0Id-event@ietf.org
&g= t;=C2=A0= https://www.ietf.org/mailman/listinfo/id-event
>=C2=A0
=
_______________________________________________
Id-event mailing l= ist
Id-event@ietf= .org
https://www.ietf.org/mailman/listinfo/id-event


--=C2=A0
Adam Dawes=C2=A0|=C2= =A0Sr. Product Manager=C2=A0|=C2=A0adawes@goo= gle.com=C2=A0|=C2= =A0+1 650-214-2410



= --=C2=A0
Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0= adawes@google.com=C2=A0|=C2=A0+1 650-214-2= 410

_______________________________________________Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.co= m/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwI= CAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWma= nqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwy= IPunbiSAQ&s=3D4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e=3D<= /div>

--0000000000008a3d4f057a4421e3-- From nobody Fri Nov 9 17:57:51 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E30130E05 for ; Fri, 9 Nov 2018 17:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.251 X-Spam-Level: X-Spam-Status: No, score=-15.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 FnKX5LUfza-C for ; Fri, 9 Nov 2018 17:57:44 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 394AA130DE8 for ; Fri, 9 Nov 2018 17:57:44 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id r14so2135236vsc.13 for ; Fri, 09 Nov 2018 17:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DQzwsi6dzHgg49TKfCIDmrVMxSTqIQwtglaCO1e54Co=; b=oNgUbWgfGr4xIaSamXtPuds4dku5JLeFDKhqy0WQ6vkYWECjag+4XMcw0Ri8+2JqkL SB+H5LptmUS9Exu79tycHQ6QtnQ1XZKz8JZrRrhNV8u5zeJUIb4xiFmnZ+Uq2LM7EpD/ SpNkhDY5zrNxVbLDIEsdIZNg+TGLrfyzLVNi1RF14FQt2aTV6UUk1OQj9lyaND6LcECb xdM48nAEKazMi5ATME8ZtHx3Eg/h+B4dSqBm3cEPMSpg254doMl5zKT/HsAF+BQSTiyX GjhrfVNxbzrChwxumGsq4zSnfxeePoDY1iMqGmf/37Q8ZAwnK63LvtDoyox3hcIiQlK2 4cQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DQzwsi6dzHgg49TKfCIDmrVMxSTqIQwtglaCO1e54Co=; b=JIUBHvQz4iZG6jqDokLxLjQ0nnyWh2LFDPgDXtzotIXKvzMFrcIn0MjXKBKgo6n1Ej 8z18mgSFN7q/aDYEau1UdlQcd3lTAyAIos/VYb4X+syJzovrg7lYGfAAPVSfxsSVe5HS xZvPLvOdotVgG/EykvYs2H8VirkO+pCDdWtbbOq6OgySvSzUicJq5kyptbyoCb2z07ga 6JFGE/4tb0uB+1x3HM8PnYca4CGMof//03uIn/pHu7ouTSTBteRAY9jYzSHqdquSfqs4 2FYh7oJMXkrTVmLoMznvU4dzzrCfufys1SU1m7hzvR95yqozAuhXkBWYmauzMmLdpr0F zrVA== X-Gm-Message-State: AGRZ1gKrH2+959eTyRZj2wxwlZgInWAsseevGxm26UGM0OTrnRjnPZnc F7aVuQAVFtuaSo/Z4nYoDCou0UcLuBYBE6m3aQ1dGw== X-Google-Smtp-Source: AJdET5eigR1aP7yu5jHLr87Uivz0E5eG5NxAEn+FmDAp5gi6WcdeGLk88vacIyqS8b/3ZXtvoU9Cds6QlqugChcCUD8= X-Received: by 2002:a67:d913:: with SMTP id t19mr4332371vsj.26.1541815062853; Fri, 09 Nov 2018 17:57:42 -0800 (PST) MIME-Version: 1.0 References: <8e117807-689e-166b-4c1c-9a4a0827ce6d@gmail.com> In-Reply-To: From: Adam Dawes Date: Fri, 9 Nov 2018 17:57:31 -0800 Message-ID: To: Dick Hardt Cc: Phil Hunt , Yaron Sheffer , ID Events Mailing List Content-Type: multipart/alternative; boundary="00000000000021cb55057a45cb94" Archived-At: Subject: Re: [Id-event] stab at describing email canonicalization dragons X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 01:57:48 -0000 --00000000000021cb55057a45cb94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 9, 2018 at 3:58 PM Dick Hardt wrote: > Phil: RFC5321 describes a valid > email address, it is not canonical. > > Adam: in my experience, we strip the dots in gmail addresses, since we > have learned that is what Google does. :) > As to the '+' functionality, some parties may use that to know it is the > same subject at the host. For example, if merchantfoo subscribed to recei= ve > events for subject alicesmith+merchantfoo@mailprovider.com > from mailprovider.com, then > mailprovider.com would canonicalize the subject to > alicesmith@mailprovider.com . > > While merchantfoo would use alicesmith+merchantfoo@mailprovider.com > for sending email, it would > likely be useful for merchantfoo to know that alicesmith@mailprovider.co= m > and > alicesmith+merchantfoo@mailprovider.com > are the same subject from a > SET point of view. For example, if merchantfoo is attempting to find mutu= al > subjects with a non-email provider, socialfoo.com, then they would > ideally both use alicesmith@mailprovider.com > even though Alice had > provided alicesmith+merchantfoo@mailprovider.com > to merchantfoor and > alicesmith+socialfoo@mailprovider.com > to socialfoo. > > Exactly right > In the WG meeting there was a discussion about standardizing > canonicalization, and the consensus in the meeting was that was out of > scope, but that it was important to call out the issue. > > +1 It is useful to alert implementers that these issues exist. As for solving the deeper problem, I was curious about whether that was being contemplated. But it seems that is out of scope. Not surprised. Always more things to do in the future! > > > > > On Sat, Nov 10, 2018 at 2:28 AM Phil Hunt wrote: > >> Why is RFC5321 not sufficient to >> define canonicalization for email addresses? >> >> Phil >> >> Oracle Corporation, Cloud Security and Identity Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Nov 9, 2018, at 10:50 AM, Adam Dawes < >> adawes=3D40google.com@dmarc.ietf.org> wrote: >> >> I think it does make sense to do the same canonicalization for SETs. But >> I suspect that most canonicalization that apps do is purely focused on >> proper lower casing. I would be more surprised if apps canonicalize on >> special characters like .,+ etc. I don't know as if there are any guidan= ce >> in the mail RFCs on how to treat these so I think there are inconsistent >> treatments from mail providers. Some apps may understand the conventions= of >> larger mail providers but I suspect you're still going to have >> discrepancies that are hard to iron out without fully understanding the >> mail provider's canonicalization scheme. And some users expect that thei= r >> mail will not be canoncialized. For example, Gmail provides the + charac= ter >> so that a user can give unique addresses to each recipient >> alice.smith+merchantfoo@mailprovider.com. If merchantfoo stripped the + >> in canonicalizing, then Alice wouldn't be able to manage mail from >> merchantfoo as easily. >> >> On Thu, Nov 8, 2018 at 4:40 PM Dick Hardt wrote: >> >>> Hey Adam >>> >>> The problem you are describing is what I was attempting to capture. >>> Since Alice mailprovider.com >>> >>> removes dots, merchantfoo.com >>> likely >>> has already figured out mailprover.com >>> 's >>> canonicalization since Alice can enter alice.smith@mailprovider.com or >>> alicesmith@mailprovider.com at any site >>> and receive email. The suggested text says merchantfoo.com >>> >>> SHOULD do the same canonicalization for email subject identifiers that >>> it already does with emails entered by the user. >>> >>> Does that make sense? Suggested changes to the text? >>> >>> >>> On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes wrote: >>> >>>> I think this makes sense. However, I wanted to point out that there's = a >>>> higher level problem in that the Transmitter is providing it's >>>> canonicalized identifier in the SET and this may not map to the receiv= er's >>>> canonicalized identifier. >>>> >>>> For example, Alice may have registered alice.smith@mailprovider.com >>>> with merchantfoo.com >>>> . >>>> When mailprovider.com >>>> >>>> sends a SET to merchantfoo.com >>>> , >>>> it could be for alicesmith@mailprovider.com >>>> >>>> merchantfoo can't effectively remap the event to the proper account on >>>> their side without first knowing mailprovider.com >>>> 's >>>> canonicalization scheme. I'm not sure what can be done about this abse= nt >>>> some way for mailprovider.com >>>> >>>> to advertise its canonicalization scheme. Is there a suggestion to do >>>> that? >>>> >>>> On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt wrote= : >>>> >>>>> Agreed. >>>>> >>>>> On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer >>>>> wrote: >>>>> >>>>>> Looks good, and I think this is a normative SHOULD. >>>>>> >>>>>> Thanks, >>>>>> Yaron >>>>>> >>>>>> On 08/11/2018 17:07, Dick Hardt wrote: >>>>>> > >>>>>> > Many email providers will treat the following email addresses as >>>>>> equivalent: >>>>>> > >>>>>> > johnsmith@example.com >>>>>> > JOHNSMITH@EXAMPLE.COM >>>>> JOHNSMITH@EXAMPLE.COM> >>>>>> > JohnSmith@example.com >>>>>> > john.smith@example.com >>>>>> > >>>>>> > This has led users to view these strings as equivalent, and has le= d >>>>>> to >>>>>> > email address canonicalization algorithms that are implementations >>>>>> > specific, so that user entered email addresses resolve to the same >>>>>> > canonical string. When receiving an email identifier, the recipie= nt >>>>>> >>>>>> > should use their implementation's canonicalization algorithm to >>>>>> resolve >>>>>> > to the same subject identifier string used in their system. >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Id-event mailing list >>>>>> > Id-event@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/id-event >>>>>> >>>>>> > >>>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf..org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> >>>> >>>> >>>> -- >>>> Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 >>>> >>>> >> >> -- >> Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 >> <+1%20650-214-2410> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D3R8Gzz4c6jGa09Z= Hko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=3D4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5= U&e=3D >> >> >> --=20 Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 --00000000000021cb55057a45cb94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Nov 9, 2018 at 3:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Phil:=C2=A0RFC5321=C2=A0describes a valid email address, = it is not canonical.=C2=A0

Adam: in my experience, we st= rip the dots in gmail addresses, since we have learned that is what Google = does. :)
As to the '+' functionality, some parties may us= e that to know it is the same subject at the host. For example, if merchant= foo subscribed to receive events for subject=C2=A0alicesmith+merchantfoo@mailprovider.com=C2= =A0from mailprovider.= com, then mailpro= vider.com would canonicalize the subject to=C2=A0 =C2=A0alicesmith@mailprovider.com.
=

While merchantfoo would use=C2=A0=C2=A0alicesmith+merchantfoo@mailprovider.com= =C2=A0for sending email, it would likely be useful for merchantfoo to k= now that=C2=A0=C2=A0ali= cesmith@mailprovider.com=C2=A0and=C2=A0 =C2=A0alicesmith+merchantfoo@mailprovider.com=C2= =A0are the same subject from a SET point of view. For example, if merchantf= oo is attempting to find mutual subjects with a non-email provider, socialfoo.com, then they wo= uld ideally both use=C2=A0=C2=A0alicesmith@mailprovider.com=C2=A0even though Alice had provide= d=C2=A0=C2=A0alicesmith= +merchantfoo@mailprovider.com=C2=A0to merchantfoor and=C2=A0=C2=A0alicesmith+socialfoo@mailpro= vider.com=C2=A0to socialfoo.

Exactly right
=C2=A0
In the WG meeting there was a discussion about s= tandardizing canonicalization, and the consensus in the meeting was that wa= s out of scope, but that it was important to call out the issue.
=
+1=C2=A0
It is useful to al= ert implementers that these issues exist. As for solving the deeper problem= , I was curious about whether that was being contemplated. But it seems tha= t is out of scope. Not surprised. Always more things to do in the future!
=C2=A0
<= /div>




On Sat, Nov 10, 2018 at 2:28 AM Phil Hunt <= phil.hunt@oracle.= com> wrote:
Why is=C2=A0RFC5321=C2=A0not su= fficient to define canonicalization for email addresses?

Phil

Or= acle Corporation, Cloud Security and Identity Architect
@independ= entid
phil.hunt@oracle.com
=

On Nov 9, 2018, at 10:50 AM, Adam D= awes <adawes=3D40google.com@dmarc.ietf.org> wrote:

<= div>
I think it does make sense to do the s= ame canonicalization for SETs. But I suspect that most canonicalization tha= t apps do is purely focused on proper lower casing. I would be more surpris= ed if apps canonicalize on special characters like .,+ etc. I don't kno= w as if there are any guidance in the mail RFCs on how to treat these so I = think there are inconsistent treatments from mail providers. Some apps may = understand the conventions of larger mail providers but I suspect you'r= e still going to have discrepancies that are hard to iron out without fully= understanding the mail provider's canonicalization scheme. And some us= ers expect that their mail will not be canoncialized. For example, Gmail pr= ovides the=C2=A0+ character so that a user can give unique addresses to eac= h recipient=C2=A0alice.smith+merchantfoo@mailprovider.com= . If merchantfoo stripped the=C2=A0+ in canonicalizing, then Alice woul= dn't be able to manage mail from merchantfoo as easily.=C2=A0

On Thu, Nov 8, 2018 at 4:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=
Hey Adam

The problem y= ou are describing is what I was attempting to capture. Since Alice=C2= =A0mailprovider.com=C2= =A0removes dots,=C2=A0= merchantfoo.comlikely has already figured out=C2=A0mailprover.com's canonicalization since Ali= ce can enter=C2=A0alice.smith@mailprovider.com=C2=A0or=C2=A0alicesmith@mailprovider.com=C2=A0at any site and receive email. The suggested text says=C2= =A0merchantfoo.com=C2=A0SHOULD do the same canonicalization for email subject identifiers that= it already does with emails entered by the user.

= Does that make sense? Suggested changes to the text?


On Fri, Nov 9, 2018 at = 4:52 AM Adam Dawes <adawes@google.com> wrote:
I think this makes sense. However, I wanted to point out that there'= ;s a higher level problem in that the Transmitter is providing it's can= onicalized identifier in the SET and this may not map to the receiver's= canonicalized identifier.=C2=A0

For example, Alice may = have registered=C2=A0alice.smith@mailprovider.com=C2=A0with=C2=A0merchantfoo.com= . When=C2=A0mailprovider.com<= /a>=C2=A0sends a SET to=C2=A0merchantfoo.com, it could be for=C2=A0alicesmith@mailpr= ovider.com

merchantfoo can't effectively r= emap the event to the proper account on their side without first knowing=C2=A0mailprovider.com's= canonicalization scheme. I'm not sure what can be done about this abse= nt some way for=C2=A0mailprov= ider.com=C2=A0to advertise its canonicalization scheme. Is= there a suggestion to do that?

<= div dir=3D"ltr">On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt <dick.hardt@gmail.com> w= rote:
Agreed.

On Thu, Nov 8, 2018 at 5:27 PM Yaron She= ffer <yaronf.= ietf@gmail.com> wrote:
Looks good, and I t= hink this is a normative SHOULD.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0Yaron

On 08/11/2018 17:07, Dick Hardt wrote:>=C2=A0
> Many email providers will treat the follo= wing email addresses as equivalent:
>=C2=A0
>=C2=A0jo= hnsmith@example.com=C2=A0<mailto:johnsmith@example.com>
><= span class=3D"m_4578789731336879722m_-4022685882050799111Apple-converted-sp= ace">=C2=A0JOHNSMITH@EXAMPLE.COM=C2=A0<mailto:JOHNSMITH@EXAMPLE.COM>
= >=C2=A0JohnSmith@example.com=C2=A0<mailto:JohnSmith@example.com>=
>=C2=A0john.smith@example.com=C2=A0<mailto:john.smith@example.com= >
>=C2=A0
> This has led users to view thes= e strings as equivalent, and has led to=C2=A0
> email ad= dress canonicalization algorithms that are implementations=C2=A0
> specific, so that user entered email addresses resolve to the sa= me=C2=A0
> canonical string.=C2=A0 When receiving an ema= il identifier, the recipient=C2=A0
> should use their im= plementation's canonicalization algorithm to resolve=C2=A0=
> to the same subject identifier string used in their system.
>= ;=C2=A0
>=C2=A0
>=C2=A0<= br>>=C2=A0
>=C2=A0
>=C2=A0
> _______________________________________________
> Id-ev= ent mailing list
>=C2=A0Id-event@ietf.org
>=C2=A0ht= tps://www.ietf.org/mailman/listinfo/id-event
>=C2=A0=
_______________________________________________
I= d-event mailing list
Id-event@ietf..org
https://www.ietf.org/mailman/listinfo/id-= event


--= =C2=A0
Adam Daw= es=C2=A0|=C2=A0Sr. Prod= uct Manager=C2=A0|=C2=A0<= a href=3D"mailto:adawes@google.com" target=3D"_blank">adawes@google.com= =C2=A0|=C2=A0+1 650-214= -2410


--=C2=A0=
<= span style=3D"border-width:2px 0px 0px;border-style:solid;border-color:rgb(= 213,15,37);padding-top:2px;margin-top:2px">Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410

__________________________= _____________________
Id-event mailing list
Id-event@ietf.org=
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIr= MUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D3= R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=3D4a2fxkjOZSARRKA7He56h0Tu= V6oAPK3SRRpCJXszW5U&e=3D



--
Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410

--00000000000021cb55057a45cb94-- From nobody Sun Nov 11 08:56:39 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397FC130DC3 for ; Sun, 11 Nov 2018 08:56:37 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI1HGcvh6bp4 for ; Sun, 11 Nov 2018 08:56:35 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 56E37130DBE for ; Sun, 11 Nov 2018 08:56:35 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id 74-v6so6781010wrb.13 for ; Sun, 11 Nov 2018 08:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=BrZQL1C8LpNOJSs9g/qBTHESDMiw1oQNlM9fNV8RZGk=; b=MjsGt4Mx8IVA2j5dVlfNXt+rTapySin7Lhq9w2ce9bkiAjl3M8TbO3czMSYCOW3oCF 9mwWd9nlvDgOWgabiSoWX3q+SW9XBai2Ux2vERVK6Pzspvgpua+U8jB1eGOnFikzH+Ub cB7Pv6QDMBkoupz/exhVeJ4wk2mUNbxnUzJEsqXsbalYI8Yuf/fgxqpmY4or3l8HRLBz yCd30iX3F5i0dqmvi+os97Y6tct7utZd5qQ9rbmvucUc1GyO30TEcSdOhJLbToztajkx G26Tw1YX+syjBdIPCFCExqFudqfAx5dT724KgjZBRBHosYOuyQuhy5/mBkf2IbunKMSZ 7HIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=BrZQL1C8LpNOJSs9g/qBTHESDMiw1oQNlM9fNV8RZGk=; b=MirU2OlFFd2NAnxHZO2M70Dvpzoh5+3cHXHsVHz0X7NGL9442HNHgQbfc+oXUajgbH ObV3sn0cv8fxdkREbsE7WjLjh90uzmAUbPKvv+M7UobVcjgS+wgiVBNz2j8t1kB5fRcH SKqtbipBj5IkPusWIjFDEMxBgeP0T5iV+mx3G5H3JxUbeU6vjkFmj1J3qyFNk06HHAor wUmb220yvVvoPe6KdpTW04/ewrZFGVIpY79mByfmABcQURjl1QXzxbX73l3BhxRyNKT+ 7tNmBmhY6q05m5QnhzzJfHA1hEX/j0MBD2txE7Qg/BNjz0wUOZ9CUscx97jOWDRYBL/o Wc1Q== X-Gm-Message-State: AGRZ1gKfNAhLdM6v9pEVfW4NmOeYlNL3QFaNoBl0DYRm3JmYh+zBQByd 9dfC/Hn09gL+bMHJBVwzsWeCoUhj X-Google-Smtp-Source: AJdET5e+mzOtnZH7Og2uSTlGicFQ6E3IGdvqVLWZX+yhMiF4GtfRZPtHY+L8Hl9hQHQqgqAIFtrq7w== X-Received: by 2002:adf:8361:: with SMTP id 88-v6mr14997841wrd.192.1541955393199; Sun, 11 Nov 2018 08:56:33 -0800 (PST) Received: from [172.18.129.22] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id g13-v6sm9187070wru.1.2018.11.11.08.56.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Nov 2018 08:56:32 -0800 (PST) To: SecEvent From: Yaron Sheffer Message-ID: <90305fd0-812c-22f1-63a1-77656dcf4131@gmail.com> Date: Sun, 11 Nov 2018 18:56:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Id-event] SecEvent minutes uploaded X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 16:56:37 -0000 Thank you Leif for taking notes! The minutes are available here: https://datatracker.ietf.org/meeting/103/materials/minutes-103-secevent-00 Please review them and let us know if we missed anything. See you all in Prague!     Yaron From nobody Sun Nov 18 00:05:38 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E0F128CE4 for ; Sun, 18 Nov 2018 00:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 d7dY5QkaFffI for ; Sun, 18 Nov 2018 00:05:35 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 A9688124D68 for ; Sun, 18 Nov 2018 00:05:34 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id u9-v6so28805904wrr.0 for ; Sun, 18 Nov 2018 00:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=NLHek9JG0wAmdaQEXYrMZd/Z1WHCIhYpSpwjYIs9zV8=; b=RCCDctFnOglP9dv7/ItpJ40tqSyrn5vGlmOyrWQq3DL1F8Ls71GJTq/TGpCucnFiXB va2ipbmfZDiGkDn2UPboF4shjwW7O74sQ8AJGqpu+WwpJyNpkEGVRwz7ibeHIJzoQWNF Zw7x0OlIVYlNKdvT8HE71bl7iWbfeYUSy7ajjIX41MuqTx9SZ6v0EiDQ8zmfSl/QT76d R8rfNoFd2UMKCsBD2drRIZnHC3tm+pjTxLWDMcjF8E9nw/V/y6CZn1cUxkL349rUcpFV YXgjR9dIMpetp1EIiLBWB4K1D/r4UOGu8nDyibVpceOE1gedYvzDIANEuqe+8jAac5aa 9QwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=NLHek9JG0wAmdaQEXYrMZd/Z1WHCIhYpSpwjYIs9zV8=; b=lFBNGwnEHQ8VKl1tvXeWJ/brKXgAI7UUa0uO0oTygUWqW3Ea8JFQ7N9dr/mR/2eiAi 6nGhEqHgohC/veY2vk+HoKPiqrMzYGfuXNEGNQBPcYxScBvQDp9wlCFJdAJw3afDp/2s Vue//FVJfPftdHgiK3MgKUkO+t1r9W527BKbC9SYc4a8uBuBTgY9kG5MKvfHUs8O0UDY BBUiEsY+9+VooyUvJg5/RewNnmZ/aOWx7W/EK9xRNA1z8HGmx79sp4QzYtSZrpvkvSO2 ZjKQUbZ4HUSZCh/ThfvZqSRaf90NX+eu2nvJwQKq8rp8kfISBhEoDerJeFfvzV5KQ9TV Dr6Q== X-Gm-Message-State: AGRZ1gKIVNQ8IPV2+BuP9MPn8x+odMj5sPNolNUpV4WSQdfdcFfCNv+w EJguZGWEXdyQOgNePQrBPjdpp+Qu X-Google-Smtp-Source: AJdET5dZ5jVQx7UiaA+Y0aHmW7+U7bZ+mYTSheccRsvqvNca409lFs/zQMBRUcxA+0iXYBZLIziHRA== X-Received: by 2002:a5d:4b8b:: with SMTP id b11-v6mr14896467wrt.72.1542528332665; Sun, 18 Nov 2018 00:05:32 -0800 (PST) Received: from [172.18.129.22] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id z17sm11745085wrv.2.2018.11.18.00.05.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Nov 2018 00:05:32 -0800 (PST) From: Yaron Sheffer To: SecEvent Message-ID: Date: Sun, 18 Nov 2018 10:05:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Id-event] Push Delivery: working group last call X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 08:05:37 -0000 Dear SecEvent participants, This is to start a 2-week working group last call on draft-ietf-secevent-http-push-03 , until Dec. 2. Please send any comments to the list. In addition, if you have no comments but support publication of this document as-is, please make your voice heard. Thanks,     Dick and Yaron From nobody Sun Nov 25 23:28:11 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49C3128CE4 for ; Sun, 25 Nov 2018 23:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wocN_Wu_zaAn for ; Sun, 25 Nov 2018 23:28:07 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 891CC1271FF for ; Sun, 25 Nov 2018 23:28:07 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id j10so17702707wru.4 for ; Sun, 25 Nov 2018 23:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=cHHozpcUAH71ay57SgugkChzTFJZ8A/4OmCVYjVNGc0=; b=JkX53W2Kg1qlJy5pGWn3pyjO86jG0INX8p0EMhf4Sj6pB1NsSajeKNRVVfeg1F8hfl BUXnfZCc3Vq2Tc9zxENd24Aca6RDOf1FM0qqO0IjvP0j3a5AW4fiFLlel5u2/HMK+PX2 h8We3Vck5U4fec7bAPhKw1ZZSTRXLV6kNVF2bVVT7Mz2vXAv7U3kCUFyFjB2xwqDKrlS J8pc3ZSqHRAIJx90daqPYey00XajZh5m4eZ6hxCClLqissHJV/o+cKH0WRLOeRRNriV5 wAsT47z7PwyWWKQE8ZJMec6Suplmf08IyBTwMZmTTQFLLtcAT2ylU81EfX11+Y7G0X+C v7aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cHHozpcUAH71ay57SgugkChzTFJZ8A/4OmCVYjVNGc0=; b=TdRQIIe5vZ6H+cYgWLVYgKqrRjB4T2jIWhcKpDzG5AGr/tbo4l0z5xudbLdHZT7efi WQATv10x44PEODjG8DIxy+bStxLTE9HxYUfAttpU5JswLH/KhlmHjzTaib/uIgsCph1p CWEdsmxSs1vvK15ekvY/SLiiYSNIVV96eLdVk2RKgiwMrBTYlo2ijo6hTKX4oRRMTJ/f cI0KjpNX62fZeEXXbzv3oh1FJWlO6Vp9i50PVHrC65mSONOEH8MQkefgrPVGqywSb/U4 fBhml27XKI9E9jSbTR4BraOHtbtEYih3yYPJxJHxSluAiSgWYgJvsum51eZ8DDypwCxt jEcQ== X-Gm-Message-State: AA+aEWa7JcQ3XB0NOKn1+U0zz1k0y0fvnOiZrCUzBMqSNwM48RmMoEWx JGEl5jYca5/U9WQX/Sog4NU8lMt7 X-Google-Smtp-Source: AFSGD/Xkp/D/3MeC/EuwyaNhuVavVRWH/FHpYFbjmEAKMozvRDeKRiqMNkrYsrrt9EkXVSy3ufk6Yg== X-Received: by 2002:adf:ec11:: with SMTP id x17mr22907339wrn.88.1543217285583; Sun, 25 Nov 2018 23:28:05 -0800 (PST) Received: from [10.0.0.145] (bzq-79-178-54-33.red.bezeqint.net. [79.178.54.33]) by smtp.gmail.com with ESMTPSA id 185sm9939662wmx.41.2018.11.25.23.28.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Nov 2018 23:28:04 -0800 (PST) From: Yaron Sheffer To: SecEvent References: Message-ID: <857da70d-15fa-c479-7e38-d2ccdd01cbd2@gmail.com> Date: Mon, 26 Nov 2018 09:28:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Id-event] Push Delivery: working group last call X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 07:28:10 -0000 We are a week into the last call and I haven't seen any responses on the list yet. Please give the document a read so we can move it forward. Thanks, Yaron On 18/11/2018 10:05, Yaron Sheffer wrote: > Dear SecEvent participants, > > > This is to start a 2-week working group last call on > draft-ietf-secevent-http-push-03 > , until > Dec. 2. Please send any comments to the list. In addition, if you have > no comments but support publication of this document as-is, please make > your voice heard. > > > Thanks, > > >     Dick and Yaron > From nobody Thu Nov 29 10:26:54 2018 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7512130E47 for ; Thu, 29 Nov 2018 10:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTXksRXrG3GI for ; Thu, 29 Nov 2018 10:26:50 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 739BB130E4B for ; Thu, 29 Nov 2018 10:26:50 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id p17so2211551lfh.4 for ; Thu, 29 Nov 2018 10:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1VKnf6tlENOo6X4krbyxRgtYf2bxKN59aDpNNS0DPyw=; b=lYAAmh8qRkjmTxAvt32KhZVeTmoX3wqTO2tncyBS3Y6id0OzqOW4o8AXd+UVJDODEn 29Mxg+wVVavHCFMk8bG46qZczDN580rXTrSUbJdMGtIAbHBoUW96I/KhWoNsMq09zw+U z6/U56Jjtl+xEf3W6la1T75TJXxe3I/gil2HdU9Gpgqq0Mxq+p6yTZTRTyty7Ou44gTP qyiQ57Ms9n4RT3p2bIYob7+6sXzhy7IumQXxJFvt80EVxy69hKzbs6uuwcCg4qu8qEsj 2ZiqNqPaErr+fL6sbY/AZi+Pfu5miP9ItbFmlCkfM77OgT1NvePdf+YZos5dZNR3vZ+q zeZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1VKnf6tlENOo6X4krbyxRgtYf2bxKN59aDpNNS0DPyw=; b=BqqjtW54TdFSmC/wwyB4zbBkOUIdPlBZCyD7RSyqELkrXVsA104nVxpzW2IXkhY9GJ eNFWKPqY0pOULsttM/XveIPtdZH1mFn2Qux3eHLV8dZOSZGOdyUpWG+3M3RbDzWDkFds z++jcOTlrQAeObNgo3jw8yjx7CIyy1Z/STf3npcq+xpfOOWi8+/zJmjL8N7fis3hjb4Q CkBe3qpLELm6mV8lK8j/uag9BvTTIUBz4sqbE2XbyEmnorLzFb8VA4EAwPOWEGnoEmbs HXRDRclN1xgdVH4N/OUTcPTk10C7FLrRpG68DnZwe1XaazEmE++bz5vNbpLL/csykiTU Z6dQ== X-Gm-Message-State: AA+aEWZa7YbIUjuLGwJeGAlGE+UoOLX7FJNAOpuS3WzfqflPDwKukqs1 xn9iyQnud5JpyRPQiDacEhK6/5jApYPjJFTjph4BHQ== X-Google-Smtp-Source: AFSGD/VqdBrtsBuJyRx9X2Ca7WSZH25Ucguvl11IFyl9HrVUHLT5eQ7z2MZ89H5J5bNDXfxni3GO2XbhKy5k5kBTKss= X-Received: by 2002:a19:9653:: with SMTP id y80mr1751150lfd.66.1543516007998; Thu, 29 Nov 2018 10:26:47 -0800 (PST) MIME-Version: 1.0 References: <857da70d-15fa-c479-7e38-d2ccdd01cbd2@gmail.com> In-Reply-To: <857da70d-15fa-c479-7e38-d2ccdd01cbd2@gmail.com> From: Dick Hardt Date: Thu, 29 Nov 2018 10:26:40 -0800 Message-ID: To: SecEvent Cc: Yaron Sheffer Content-Type: multipart/alternative; boundary="0000000000005caa35057bd1d391" Archived-At: Subject: Re: [Id-event] Push Delivery: working group last call X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2018 18:26:53 -0000 --0000000000005caa35057bd1d391 Content-Type: text/plain; charset="UTF-8" Hey everyone, reminder to review the Push draft. Thanks! On Sun, Nov 25, 2018 at 11:28 PM Yaron Sheffer wrote: > We are a week into the last call and I haven't seen any responses on the > list yet. Please give the document a read so we can move it forward. > > Thanks, > Yaron > > On 18/11/2018 10:05, Yaron Sheffer wrote: > > Dear SecEvent participants, > > > > > > This is to start a 2-week working group last call on > > draft-ietf-secevent-http-push-03 > > , > until > > Dec. 2. Please send any comments to the list. In addition, if you have > > no comments but support publication of this document as-is, please make > > your voice heard. > > > > > > Thanks, > > > > > > Dick and Yaron > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --0000000000005caa35057bd1d391 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey everyone, reminder to review the Push draft. Thanks!
On Sun, Nov 25, 2018 at= 11:28 PM Yaron Sheffer <yaronf= .ietf@gmail.com> wrote:
We a= re a week into the last call and I haven't seen any responses on the list yet. Please give the document a read so we can move it forward.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 18/11/2018 10:05, Yaron Sheffer wrote:
> Dear SecEvent participants,
>
>
> This is to start a 2-week working group last call on
> draft-ietf-secevent-http-push-03
> <https://datatracker.ietf.org= /doc/draft-ietf-secevent-http-push/>, until
> Dec. 2. Please send any comments to the list. In addition, if you have=
> no comments but support publication of this document as-is, please mak= e
> your voice heard.
>
>
> Thanks,
>
>
>=C2=A0 =C2=A0=C2=A0=C2=A0 Dick and Yaron
>

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--0000000000005caa35057bd1d391--