[art] Artart Last Call review of draft-ietf-secevent-subject-identifiers-14
Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 11 November 2022 18:22 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097A6C1524A9; Fri, 11 Nov 2022 10:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp1CsL15qHIV; Fri, 11 Nov 2022 10:22:08 -0800 (PST)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2058.outbound.protection.outlook.com [40.107.94.58]) (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 B3ECAC1522DC; Fri, 11 Nov 2022 10:22:05 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jArVFpZc8VBx5AgFHY0FP3xb6afXFjbKpP4kyo4bAD8M30bGw0af+y5TXDy6o/QTvVu7cP9zQLQAR/hMVgtxRysqYIHJsRel+bcO8c9w00Xj6bzDgfV9xXowHTyNpLm5oaqH5udtDX9nfdO8ojUtjaPcNXQQGtIqZxrq7hU34kzsZOT6CcSB8SOujJka1Gs6ODMZzgadN1u4P6UlKySZ9Exk4Rc3TfBVQ0VJIhYX6xCb2VhfIkOfWhIJs3gJ0oXWGaR2tFJN3VcrfddynAPgkgDkc/e3to4xCPycXUUR0yrmSTRNk5wojfSPyxzNZK5yLyTDewyISya3K98mtoLzow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SdBCZt38Q7LoXtKu+2YZAGZAvw+1H088fU9ApSbErlM=; b=ZUWp/ZFpqA48vaT8GrcLc4W6D2dA8yaIe4KdnuE6Bo/w3KX9f15TLGmYQbphGk6mV9Z/+FId9cRROtuBRxQB6zj0WW7cweT0ACsigbf6SqRWLaXRYZDSjjB6/GngioTbL9M2y8pDwPZgkIVh+0QDuFAnRgk2tbHKtB11cc2PFuWoSlztX6jkEkNNqWFPz4rCvQEplDthTX0p0ufD7JEc/cwu9imxnBcWS8hcmxfV5qe01Af7Gw9K5aVqkcLGjp0bNoIndSTZqzD4+Rn/SxseDwjiEtq+4nFKW+yapBpGx5pDuWCdmZ3W6ILjqMdxhqJ/37Eimwp/LUGRDxWflv8apw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=alum.mit.edu smtp.mailfrom=alum.mit.edu; dmarc=pass (p=none sp=none pct=100) action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SdBCZt38Q7LoXtKu+2YZAGZAvw+1H088fU9ApSbErlM=; b=QotZMNaZDR16Tt4SA8fTKnobUW4ai8MMWADAKrePoT/f0IFo9ahZQ0ym2MAIFhq3mPI74LMvx7uZhfTwHMJdy5F03cXPgFckoDbTeu28vN+MJ9O/cDcZVDUPJAs5bXOB4FPHNXK3NwaNbQilWZsIDKzfyKLd4ghTAJ85Cu/MWys=
Received: from BN9PR03CA0258.namprd03.prod.outlook.com (2603:10b6:408:ff::23) by SJ1PR12MB6268.namprd12.prod.outlook.com (2603:10b6:a03:455::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.13; Fri, 11 Nov 2022 18:22:01 +0000
Received: from BN1NAM02FT047.eop-nam02.prod.protection.outlook.com (2603:10b6:408:ff:cafe::6c) by BN9PR03CA0258.outlook.office365.com (2603:10b6:408:ff::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.14 via Frontend Transport; Fri, 11 Nov 2022 18:22:00 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; pr=C
Received: from outgoing-alum.mit.edu (18.7.68.33) by BN1NAM02FT047.mail.protection.outlook.com (10.13.3.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.12 via Frontend Transport; Fri, 11 Nov 2022 18:22:00 +0000
Received: from [192.168.1.52] (c-24-62-106-242.hsd1.ma.comcast.net [24.62.106.242]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 2ABILwke021856 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 11 Nov 2022 13:21:59 -0500
Message-ID: <d7129013-5325-ff50-7119-150d63a756b2@alum.mit.edu>
Date: Fri, 11 Nov 2022 13:21:57 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: art@ietf.org
Cc: draft-ietf-secevent-subject-identifiers.all@ietf.org
Content-Language: en-US
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1NAM02FT047:EE_|SJ1PR12MB6268:EE_
X-MS-Office365-Filtering-Correlation-Id: 745bef53-71ce-4421-ed4e-08dac4119ffd
X-LD-Processed: 3326b102-c043-408b-a990-b89e477d582f,ExtAddr,ExtFwd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 7CCCbRtO3TS8D4J9DsIFUlr6FlNtzPlET6pGEqEFOkY7CU5jZPmh52lpw6NhdDZMRIeIEmm96Teh7w47v5b4FE+WTPsIDeO5cknoqUNhZSyn9sCGyx7pA+T6iPDm0JZHktkX4OYJZ0Y27eAlZFwi6vTiox/eOVrID4wV+F2QYY/xwewk9TOobZO0ZQKlzobEuDWYEfdyKv3IpULBGgnIANSxnML8xf5M8pXeD52cBZqw2GFKQY8bM89f1HShY739PnlHyCcVxniGvd19uWaZyOWxznjn1Bhk9zwdZemr1XpOtYcl/TWueXVeglUtzLWfu59K/1zZFmkM9ip7DzUKJ+MPsmAI402x/TnO9sn3YfB/DlxnLcUxd8V/HJnsWoiEGiFKWiTZGEpN7lDBjpWm7OUrmzf44ND0/VUiuwYOCwPIzHN+EjFpm1mKaaDMMji3qOfLMjrS3wyEXAYjR5liLRE6g8olRdsIrjTL1jLrSY2KJ6GqhIX+B4dosvw6Ld9Y49TJxws8LFcNczZlMtMevH3EocNN8/3k9kccb+keY4QL8ZJcIzHmK4Uu4fCRPfiqL+FbqxMxqEND3aYj1sCPHVcyoyPvbRWg9WK/MWja05BbscoafDcZL78BIaYTeUQaAaW2OYh0wqjKqF2NfsWU77BSba/aiVg5veOldSrRni8ZzURGlym3qwVdJz/l3DAjyC1e0kBLD6+1JSbmvxuu03dzYujinOYCCMOQs0HaIfpWVj+QfXZ9uZx8fbrdEAZawcapgy7FIU8uouOUEe+KVvhIsd7+kFFH9mPzzYyyRZ0Jk/yq8dNikZD4OOQp3z/Y
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(13230022)(136003)(376002)(346002)(39860400002)(396003)(451199015)(46966006)(36840700001)(40470700004)(82740400003)(5660300002)(83380400001)(31686004)(8936002)(36860700001)(75432002)(41300700001)(82310400005)(356005)(7596003)(40480700001)(26005)(70586007)(186003)(450100002)(2616005)(956004)(786003)(336012)(316002)(41320700001)(66574015)(47076005)(6916009)(31696002)(4326008)(40460700003)(8676002)(4001150100001)(66899015)(70206006)(2906002)(478600001)(86362001)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2022 18:22:00.3428 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 745bef53-71ce-4421-ed4e-08dac4119ffd
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT047.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6268
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/3UoUPXy96ynW4msza41RfQqzsss>
Subject: [art] Artart Last Call review of draft-ietf-secevent-subject-identifiers-14
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Nov 2022 18:22:11 -0000
Reviewer: Paul Kyzivat Review result: Ready with Issues I am the assigned ARTART reviewer for this Internet-Draft. Document: draft-ietf-secevent-subject-identifiers-14 Reviewer: Paul Kyzivat Review Date: 2022-11-11 IETF LC End Date: 2022-11-17 IESG Telechat date: ? Summary: Ready with Issues Issues: 7 Nits: 0 1) ISSUE: Section 3, Collision-Resistant Names The use of Collision-Resistant Names, as specified in the following: Every Identifier Format MUST have a unique name registered in the IANA "Security Event Identifier Formats" registry established by Section 8.1, or a Collision-Resistant Name as defined in [RFC7519]. is problematic. A collision-resistant name is only collision resistant with other names that follow the same rules. You can't mix names of constructed using independent rules and be confident there will be no collisions. To provide a safe way to use unregistered names you really need to choose a *particular* collision-resistant format. For instance, DNS names, or URNs. I realize this approach was copied from RFC7519. The problem also exists there. 2) ISSUE: Section 3.2.1, "Account" definition This section says that the specified URI must identify an *account*. Is there any definition of "account" that would allow me to distinguish an uri that identifies one from a uri that doesn't? Needs clarification. 3) ISSUE: Section 3.2.2.1, Email Canonicalization I see a potential issue with this: ... When receiving an Email Subject Identifier, the recipient SHOULD use their implementation's canonicalization algorithm to resolve the email address to the same string used in their system. This algorithm may only be known to the email server implementation. The recipient of an email subject identifier may be distinct from the email server itself, and may deal with email addresses of multiple email servers. Is it reasonable to think it will necessarily know how to do this canonicalization? This places some constraints on how email subject ids are used. It would be helpful for the document to discuss this. 4) ISSUE: Section 3.2.4, Opaque Identifier Format I don't understand how opaque identifiers work. The sender and recipient must agree on the domain indexed by the identifier. How is that ensured? Please clarify. 5) ISSUE: Section 3.2.5, Phone Number Identifier Format This says the phone number is to be formatted according to E.164. But the example starts with "+" which is not used in E.164. The "+" is used for "global-number" in the tel: URI format (RFC3966). That is what is often used in IETF documents for representing E.164 numbers. Be clear and consistent about which format you are using. If it is RFC3966, then you need to decide whether to also allow local-numbers and if so what that means. 6) ISSUE: Section 8.1.2, Change Controller The definition and identification of Change Controller is vague. It isn't clear how to distinguish a valid value from an invalid one. 7) ISSUE: Section 8.1.2, Defining Document The following wording for Defining Document is problematic: ... The definition MUST specify the name, format, and meaning of each member that may occur within a Subject Identifier of the defined format, as well as whether each member is optional, required, prohibited, or the circumstances under which the member may be optional, required, or prohibited. This says that you can specify a member that *may occur* and then specify that it is *prohibited*. There seem to be two sub-cases here: - a name that must *never* be used as a member name; - a name that is only valid when certain conditions are met. Some better wording would help.
- [art] Artart Last Call review of draft-ietf-secev… Paul Kyzivat