Re: [pkix] Is it time for a pkix extensions (or similar) wg?

"Miller, Timothy J." <tmiller@mitre.org> Mon, 08 February 2016 14:25 UTC

Return-Path: <tmiller@mitre.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE45B1B2BE2 for <pkix@ietfa.amsl.com>; Mon, 8 Feb 2016 06:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 gsXw3e-AV7xz for <pkix@ietfa.amsl.com>; Mon, 8 Feb 2016 06:24:56 -0800 (PST)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 675AA1B2BBD for <pkix@ietf.org>; Mon, 8 Feb 2016 06:24:56 -0800 (PST)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 006D96C06B8; Mon, 8 Feb 2016 09:24:55 -0500 (EST)
Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id CCE3E6C06BA; Mon, 8 Feb 2016 09:24:55 -0500 (EST)
Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 8 Feb 2016 09:24:55 -0500
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Mon, 8 Feb 2016 09:24:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FYi3BpsAUBtBPfs0mjPOsdgJsxACjU+ag1CkNZhYfSg=; b=AhBalYjuWbP6hL7oIoQbbaKjKod+RhTNh06L5/yrQJUB/cX7dxTAwafJUqeu1rSABISDTwLUTHaeQ5kerSAul63qlp9+14gQO6KueiKASNREc7w0F3NvEaxn9XXC4mcN6vicVutPFPTkidPcRG1yklct6Fp6ogg6fNtybnMyW2E=
Received: from BY1PR09MB0920.namprd09.prod.outlook.com (10.162.144.157) by BY1PR09MB0919.namprd09.prod.outlook.com (10.162.144.156) with Microsoft SMTP Server (TLS) id 15.1.403.16; Mon, 8 Feb 2016 14:24:54 +0000
Received: from BY1PR09MB0920.namprd09.prod.outlook.com ([10.162.144.157]) by BY1PR09MB0920.namprd09.prod.outlook.com ([10.162.144.157]) with mapi id 15.01.0403.017; Mon, 8 Feb 2016 14:24:54 +0000
From: "Miller, Timothy J." <tmiller@mitre.org>
To: Wei Chuang <weihaw@google.com>, Peter Bowen <pzbowen@gmail.com>
Thread-Topic: [pkix] Is it time for a pkix extensions (or similar) wg?
Thread-Index: AQHRYAxIK5WKIQlFM0OgvJf7FkckTJ8eCiUAgAE6g4CAAY6IgIABXMIw
Date: Mon, 08 Feb 2016 14:24:54 +0000
Message-ID: <BY1PR09MB09200956B7904ED36ADA415FAED50@BY1PR09MB0920.namprd09.prod.outlook.com>
References: <56B48DED.5080202@cs.tcd.ie> <CAAFsWK2czHNii6xS-Lh86y3cz6NGvUvnCdmg4hEMMYMHgvP+fg@mail.gmail.com> <CAK6vND86rUCjjgBo4TY1SxFjO9zP+MkzjUvkq+cU0anJ+V5XCQ@mail.gmail.com> <CAAFsWK1e+DAX-vU1nOHNSOzqJoS5xbxUgj33L-RRuLqach7KJA@mail.gmail.com>
In-Reply-To: <CAAFsWK1e+DAX-vU1nOHNSOzqJoS5xbxUgj33L-RRuLqach7KJA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=mitre.org;
x-originating-ip: [192.160.51.86]
x-microsoft-exchange-diagnostics: 1; BY1PR09MB0919; 5:jv7/5HBq7hyAWeM1IlBg9poVpdh2SoG0P8vVvh/8PAeTgbFeLw6h+cqegAzdOwyVe4sBacu3LMXKsE095FZJah+p7zlJ+kKYCrrzYwJoF3y3WYG6sdBlm9iMge/OF4ZShKN898kBXd14jMjHLDGbgw==; 24:LfTydopgEaBEvt5fcKZQUsNqwM2kNcXzFWXXPuUtEjS3+XoOqWq95O30XYf0B0jbj/jUW64FKLyW3NwQb9P/JoBqnZ6zTfdVcDRwtLqmHAA=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0919;
x-ms-office365-filtering-correlation-id: abe00201-7e1d-4d25-c804-08d330939d30
x-microsoft-antispam-prvs: <BY1PR09MB09196FA00CCB9781AB9F8EEDAED50@BY1PR09MB0919.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY1PR09MB0919; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0919;
x-forefront-prvs: 084674B2CF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(76176999)(50986999)(54356999)(99286002)(86362001)(77096005)(33656002)(74316001)(87936001)(106116001)(5002640100001)(5003600100002)(2950100001)(2900100001)(19580405001)(66066001)(19580395003)(92566002)(6116002)(102836003)(3846002)(586003)(93886004)(3280700002)(76576001)(11100500001)(4326007)(2906002)(5001770100001)(122556002)(189998001)(40100003)(5001960100002)(5008740100001)(1220700001)(3660700001)(1096002)(5004730100002)(10400500002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR09MB0919; H:BY1PR09MB0920.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2016 14:24:54.1011 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0919
X-OriginatorOrg: mitre.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/2jjISZ40aH3z8ChmjG31re-voOA>
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] Is it time for a pkix extensions (or similar) wg?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 14:25:00 -0000

> I believe there RFC5321 in the context of mail delivery, says SMTP must
> preserve the case for interoperability.  

OK, so this is a long-running topic that periodically raises its head.

An MTA and MUA must preserve the local-part case of any address it handles because there's no way to signal how a non-local MTA or MUA will handle different casings.  The SHOULD clause in 4.1.2 is a good recommendation for interoperability, but the installed base of MTA/MUA have behaviors consistent with the MUST in 2.3.11.  For the vast, vast VAST, VAAAAAST majority of email, this isn't a problem.  Sending & receiving MUAs work, and intervening MTA get mail where it needs to go.

A problem appears only in S/MIME processing.  S/MIME requires that the address be encoded in the cert, but which version?  Should it be FOO@bar.com or foo@bar.com or fOO@bar.com or fOo@bar.com or Foo@bar.com or ...?  In the end it doesn't matter; an MUA that has case semantics *as allowed by 5321* will eventually flag such some S/MIME messages as a problem.

How would you put a fix in 5280?  You could, say, require that all rfc822Names be lcased, but that doesn't change how mail is handled, and you *will* end up with MUAs mishandling message security (e.g., by conflating two distinct users as one, violating confidentiality about 25% the time and causing inability to read enveloped messages another 25% of the time--not a good outcome).

You could encode a flag into an extension that defines the match semantics for rfc822Names--but certificates are issued separately from MUA and MTA deployments.  What happens when you encode one semantic rule into the certs and then later replace the MUA that uses a different semantic rule?

OTOH, you could attempt to fix email by defining the local-part semantics fully and eliminate the option.  But there's a large installed software base that both do and don't treat case as distinct, and *no* incentive to fix  it--email *works,* and S/MIME is a tiny, tiny, TINY (did I say TIIIIINNNNNYYYYYYYYY) fraction of the total.

A good alternative is to have implementation considerations for S/MIME MUAs, such that local-part semantics can be defined as needed, or provide indicators to the user as to what's going on.

Guess what?  RFC 5750 already has that recommendation (Sec 3, para 5):

"""
   Sending agents SHOULD make the address in the From or Sender header
   in a mail message match an Internet mail address in the signer's
   certificate.  Receiving agents MUST check that the address in the
   From or Sender header of a mail message matches an Internet mail
   address, if present, in the signer's certificate, if mail addresses
   are present in the certificate.  A receiving agent SHOULD provide
   some explicit alternate processing of the message if this comparison
   fails, which may be to display a message that shows the recipient the
   addresses in the certificate or other certificate details.
"""

The fact that any given MUA doesn't implement this option is a complaint to take up with that particular vendor (*cough*Apple*cough*).  Microsoft Outlook users on Windows should Google "SupressNameChecks" [sic]. 

;)

-- T