Re: [Uta] Adoption of draft-rsalz-use-san

"Salz, Rich" <rsalz@akamai.com> Wed, 17 March 2021 19:38 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E573A1259; Wed, 17 Mar 2021 12:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux1bwSxvPTo1; Wed, 17 Mar 2021 12:38:32 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA1E3A1258; Wed, 17 Mar 2021 12:38:32 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 12HJXcsf014572; Wed, 17 Mar 2021 19:38:29 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=JldB8MWIBkZRy5P6UgJTrOD3KlgAZuPVYKUi0/RMB6g=; b=A2TMVNjf8YCwifoW4qs7+BbbsFzckH8bsmYpKVm9X+AIo9wqJZ4emi+ASNrRgfXcmJN1 Py+jg+IZwdM3zyqiH6XNQI87ehje25197l45DfItyHbgXRUU+ODF+k3CKwy9/hKwFAQ2 eg8hAYWWW2PRSuf0MWciU883BWO/bxG2ME1jEk7cUBRrcq1//tHR0m6mrq15uMdLZkif awsXnguwjbuMV7y5oYHYNWi6oAWJouFahSdf5n6TR9wj9p3sEAiVm9yN41KLCLhhfPkx GYpW7GH3sLfP5T5UnyElSmvTkCcQFtymuCIjRmKGT0SfCNNB5taVSAZ9dZAowmWn8aFu Vw==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 37b57wp2bq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Mar 2021 19:38:29 +0000
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 12HJYFka031027; Wed, 17 Mar 2021 12:38:28 -0700
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint5.akamai.com with ESMTP id 378v8fh39k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Mar 2021 12:38:28 -0700
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 17 Mar 2021 15:38:27 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.012; Wed, 17 Mar 2021 15:38:27 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Brian Smith <brian@briansmith.org>, Leif Johansson <leifj@sunet.se>
CC: Valery Smyslov <smyslov.ietf@gmail.com>, "uta@ietf.org" <uta@ietf.org>, "uta-chairs@ietf.org" <uta-chairs@ietf.org>
Thread-Topic: [Uta] Adoption of draft-rsalz-use-san
Thread-Index: AdcY4OZxqBPuO31IROyAiwXQIPnE5gAWuNaAABvqAIAAGgacgABZPw6A///ZIQA=
Date: Wed, 17 Mar 2021 19:38:26 +0000
Message-ID: <4C458053-8ED0-4316-8904-672D9A06B460@akamai.com>
References: <004201d718e1$007959a0$016c0ce0$@gmail.com> <CAFewVt7qE=nmxCMhkW_y0gwt=4Vk_Ov2bbVCm-yFqfNx7unckA@mail.gmail.com> <9B34C68D-E390-40DA-BF19-29F98BEF0C33@akamai.com> <d97e7269-4ee1-aa78-04a7-5292c90b4a29@sunet.se> <CAFewVt4FSC9FjnVk0CGQGsVAh22YPFuucPmCyTZaT1Cq-LHxsQ@mail.gmail.com>
In-Reply-To: <CAFewVt4FSC9FjnVk0CGQGsVAh22YPFuucPmCyTZaT1Cq-LHxsQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.47.21031401
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: multipart/alternative; boundary="_000_4C4580538ED043168904672D9A06B460akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-17_11:2021-03-17, 2021-03-17 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 suspectscore=0 mlxlogscore=931 spamscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103170135
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-17_11:2021-03-17, 2021-03-17 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 mlxlogscore=838 bulkscore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103170135
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.60) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint5
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/_CTMHwbA5Ck98T7-a7yyPcWG9G4>
Subject: Re: [Uta] Adoption of draft-rsalz-use-san
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Mar 2021 19:38:34 -0000

  *   It actually looks pretty good to me. The only thing I disagree with is "Severs either MUST NOT issue a CN-ID, or MUST use a form for the Common Name RDN that cannot be mistaken for an identifier" and similar language. It would be better to let people put whatever they want in the CN field of the subject whether or not it looks like a domain name. As long as conformant clients stop using the CN as a dNSName/iPAddress SAN alternative, then it doesn't matter what's in the CN. Probably some users will need to duplicate what's in the SAN in the subject CN for backward compatibility with nonconformant verifiers.

That’s a good point.  If the doc focuses purely on client behavior then that makes it easier for legacy, such as Elliot’s vehicle issue, and also makes it more clear about the wildcards.