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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AE45B1B2BE2 for <>; Mon, 8 Feb 2016 06:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gsXw3e-AV7xz for <>; Mon, 8 Feb 2016 06:24:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 675AA1B2BBD for <>; Mon, 8 Feb 2016 06:24:56 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 006D96C06B8; Mon, 8 Feb 2016 09:24:55 -0500 (EST)
Received: from imshyb01.MITRE.ORG ( []) by (Postfix) with ESMTP id CCE3E6C06BA; Mon, 8 Feb 2016 09:24:55 -0500 (EST)
Received: from imshyb02.MITRE.ORG ( by imshyb01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 8 Feb 2016 09:24:55 -0500
Received: from ( by imshyb02.MITRE.ORG ( 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;; 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 ( by ( with Microsoft SMTP Server (TLS) id 15.1.403.16; Mon, 8 Feb 2016 14:24:54 +0000
Received: from ([]) by ([]) with mapi id 15.01.0403.017; Mon, 8 Feb 2016 14:24:54 +0000
From: "Miller, Timothy J." <>
To: Wei Chuang <>, Peter Bowen <>
Thread-Topic: [pkix] Is it time for a pkix extensions (or similar) wg?
Date: Mon, 08 Feb 2016 14:24:54 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
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: <>
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;; 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
Archived-At: <>
Cc: pkix <>
Subject: Re: [pkix] Is it time for a pkix extensions (or similar) wg?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 or or or or 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