IETF Logo Mail Archive

Re: [Iotops] [Uta] How should we change draft-ietf-use-san?

"Salz, Rich" <rsalz@akamai.com> Thu, 22 April 2021 17:48 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001063A1047; Thu, 22 Apr 2021 10:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0wi4J0aNKZbk; Thu, 22 Apr 2021 10:48:53 -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 DC6823A1041; Thu, 22 Apr 2021 10:48:52 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13MHdbpE012659; Thu, 22 Apr 2021 18:48:45 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=MC7mNysKSSkmtxwAMiv2fFvnszcnXFjrfLVTZkdCSYg=; b=R4uX0JvjlXEkpohaEkKL9RRm/0/N302uk5+1ZuygAULZqM8lNdXA6udvZC/NZP3b8j+y Q2A23lkAOuaXYhh4qJOkb4dbcBWg5Vwkkxr5lsWZuI7vIBCXg/3gsufTaSERjmGiudtV qWdrl6jkdsRY6pXdcFX2JuB0efz3RaqRVnJfJ3DeYYY+NSiqbdQ1JIAy1pUw4RmOSeTg tIdrIFmwtRvbLm436EsQ0qzWscKtPx/9a0UszyBjPYoR3M3vu5tGpBqYc6T2ekQnrSLM IE1lpAkp336diNDyNm9T2RKgOl0blChScKoQqE6Nc0gFOMsPECXnY23yZYvtqlORVmav Uw==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 382nw91mfa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Apr 2021 18:48:45 +0100
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 13MHZ40t013260; Thu, 22 Apr 2021 10:48:44 -0700
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint5.akamai.com with ESMTP id 382mnftmew-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Apr 2021 10:48:44 -0700
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Apr 2021 13:48:44 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Apr 2021 13:48:43 -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.015; Thu, 22 Apr 2021 13:48:43 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Eliot Lear <lear@cisco.com>, Brian Smith <brian@briansmith.org>
CC: Jim Fenton <fenton@bluepopcorn.net>, "uta@ietf.org" <uta@ietf.org>, "iotops@ietf.org" <iotops@ietf.org>
Thread-Topic: [Uta] How should we change draft-ietf-use-san?
Thread-Index: AQHXNTnKHqROQqsINkafTpLDOH8k26q8cbwAgAA0N4CAAJNJAIAAPXSAgABOooCAAItgAIAAmSMAgACMwQCAAA/GAIAAGn6AgAAGXYCAAAvugIABLD4AgAAqioCAAAF8AP//yZmA
Date: Thu, 22 Apr 2021 17:48:42 +0000
Message-ID: <99B5A119-8CF2-4D3C-9D24-ADCC52D017A2@akamai.com>
References: <F538FFD7-D172-4AEE-82DD-CF6F93936C3B@akamai.com> <D341C730-EBA1-4BF5-B200-0BE1A4B8A1D0@cisco.com> <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <A5B94C6E-419D-454E-92E8-FEEB5F8EDE17@cisco.com> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <CAFewVt4Pm6-T3XC65uEceuzpXjNubEYLWY9h1cmHdNBPcpOVXQ@mail.gmail.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> <CAFewVt57M=o=2FOsCi4s_wZ-KQbZFZQiBCQZAEgtZB4HtFvtnw@mail.gmail.com> <CA66BC31-B56B-4E4C-A3D6-F5C36FD54B38@cisco.com> <CAFewVt4XcBd0MWmtcM4kZzqQ3EQVM=t8-eqqpDMtfgNmV92u1Q@mail.gmail.com> <4233FD89-F22D-4D09-8280-8D43453E6BD7@cisco.com> <CAFewVt4eB5de2eJKupBCk_DbtSaAUGGoRETSXZrDWVxfTFcWBQ@mail.gmail.com> <B9193ABC-3E17-4110-B1B4-207383CCCD8F@cisco.com> <CAFewVt7=Lh7sunDEcYJESZHOLsYSyOycmwWmAeYBYDED8sCavg@mail.gmail.com> <184E8EE9-BD98-4887-BC01-E74FB6943600@cisco.com>
In-Reply-To: <184E8EE9-BD98-4887-BC01-E74FB6943600@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.48.21041102
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: multipart/alternative; boundary="_000_99B5A1198CF24D3C9D24ADCC52D017A2akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-22_12:2021-04-22, 2021-04-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104220132
X-Proofpoint-ORIG-GUID: wFfMC7NrPewFjNxX2PpzoNu3bwWUmVO8
X-Proofpoint-GUID: wFfMC7NrPewFjNxX2PpzoNu3bwWUmVO8
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-22_12:2021-04-22, 2021-04-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 clxscore=1011 adultscore=0 bulkscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104220133
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/iotops/v-Z477fLTKpBLislGW0RLUmqxQ8>
Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san?
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2021 17:48:58 -0000

I am beginning to think that doing a complete re-issue of 6125 will be better, because trying to fit the “patch” described below seems awkward.  On the other hand, if anyone has suggestions on how to do that, please post or email or make a PR at https://github.com/richsalz/draft-rsalz-use-san

From: Eliot Lear <lear@cisco.com>
Date: Thursday, April 22, 2021 at 1:03 PM
To: Brian Smith <brian@briansmith.org>
Cc: Rich Salz <rsalz@akamai.com>, Jim Fenton <fenton@bluepopcorn.net>, "uta@ietf.org" <uta@ietf.org>, <iotops@ietf.org>
Subject: Re: [Uta] How should we change draft-ietf-use-san?

Thanks, Brian.  I appreciate your patience.  The below totally works for me.


Eliot


On 22 Apr 2021, at 18:58, Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>> wrote:

Eliot Lear <lear@cisco.com<mailto:lear@cisco.com>> wrote:
Actually, according to 802.1AR-2009, the subject MUST contain requires a DN with serial number, and it may contain a SAN (e.g., don’t count on it).  That’s the major concern.  To me, the rest is really negotiable.

OK, great. I don't think what Rich or what I'm proposing is in conflict with that at all.

The idea here is to tell certificate verifiers (relying parties):
* If you're looking for a DNS name in a certificate, only look in the subjectAltName, Don't look in the Subject Common Name.
* If you're looking for an IP address in a certificate, only look in the subjectAltName,  Don't look in the Subject Common Name.

That's it.

In the case of  802.1AR-2009, the verifier is to look for a distinguished name (either the Subject or a directoryName subjectAltName), not a DNS name or an IP address, so the proposed guidance wouldn't apply.

Note that RFC 6125 punted in IP addresses because they weren't commonly used in certificates in the working groups' judgement at the time, but now I think it is clear that an update to RFC 6125 should address IP addresses too.

Cheers,
Brian

v2.23.0 | Report a Bug | By Email