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

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Feb 2016 11:56:29 +0000

Hiya,

We seem to be seeing a number of drafts that folks are
writing that define new certificate extensions or that
want to update/modify PKIX specs.

Do folks think it is now time to form a working group
to process those?

If no, please say why.

If yes, please say what draft(s) and propose any other
scoping. If you know of people who are or would implement
and deploy, that is very useful information. (It is fine
to say "I think we should work on topic <foo>" but it is
*much* better if you can point at a draft you've written
about <foo> and say that you or someone is implementing
that and that it'll get deployed.)

If you think this requires face to face discussion at
IETF95 (e.g. to tease out scope) please say that too.
We still have a couple of weeks before the BoF deadline
and if a short session is needed that can be arranged.
Note though that there is no need to have such a BoF
session to form a WG, if everything is clear already.

FWIW, my impression is that we do seem to have a handful
of drafts where folks seem willing to do the work and
where the work might be (or has been) implemented. So
if there's enough interest, I'd be supportive of forming
a (hopefully:-) short-lived, tightly scoped, WG to handle
that work.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Feb 2016 13:16:48 +0100

Hi Stephen, and thanks for this note.  Please see below:

> that and that it'll get deployed.)

I've written draft-lear-ietf-pkix-mud-extension-00.txt that talks about
something called a manufacturer usage description.  The idea is to
provide a means for local networks to retrieve recommendations from
manufacturers on what sort of access their devices should have.  This
extension is intended for use in the context of IEEE 802.1AR.

It definitely could use a good set of eyes on it.  We are currently in
the lab with the concept now.
> IETF95 (e.g. to tease out scope) please say that too.

I am personally okay with any approach to move forward, whether that's a
WG, doing something AD-sponsored, or something else.  I'm hoping that as
non-critical constraints go this one is not particularly controversial. 
If a working group is the best way, I would just ask that this draft be
included in scope ;-)

Eliot

---

From: Wei Chuang <[email-masked]>
Date: Fri, 5 Feb 2016 14:32:40 -0800

> Do folks think it is now time to form a working group

Yes.

> that and that it'll get deployed.)

We are interested in specifying internationalization support for the email
address local-part, and we've written a draft for that:
http://www.ietf.org/id/draft-lbaudoin-iemax-02.txt
We're aware of at least one other prior draft on this topic.

Another related but distinct area of work would be handling the discrepancy
between mail providers treating email addresses as case insensitive (and is
acknowledged in RFC5321) yet is required by RFC5280.  Moreover some email
providers have other complicated normalization rules e.g. Gmail.  We don't
have a draft for this topic but could write something up.

> a (hopefully:-) short-lived, tightly scoped, WG to handle

+1

That would be much appreciated.

-Wei

> Cheers,
> S.
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Wei Chuang <[email-masked]>
Date: Fri, 5 Feb 2016 23:23:54 -0800

On Fri, Feb 5, 2016 at 2:32 PM, Wei Chuang <[email-masked]> wrote:

>
>
> On Fri, Feb 5, 2016 at 3:56 AM, Stephen Farrell <[email-masked]
> > wrote:
>
>>
>> Hiya,
>>

Mentioned else where but also updating Unicode in query and path parts of
the URL in uniformResourceIdentifier should also be considered for in scope
of the WG.  Would definitely need help here with a draft as I'm not as
familiar with URL precedence as with email.

-Wei

> Another related but distinct area of work would be handling the
> discrepancy between mail providers treating email addresses as case
> insensitive (and is acknowledged in RFC5321) yet is required by RFC5280.
> Moreover some email providers have other complicated normalization rules
> e.g. Gmail.  We don't have a draft for this topic but could write something
> up.
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 6 Feb 2016 16:54:32 +0000

Hi,

> On 5 Feb 2016, at 22:32, Wei Chuang <[email-masked]> wrote:
> 
>> On Fri, Feb 5, 2016 at 3:56 AM, Stephen Farrell <[email-masked]> wrote:
>> 
>> Hiya,
>> 

+1
> We are interested in specifying internationalization support for the email address local-part, and we've written a draft for that:

Indeed:

https://www.ietf.org/archive/id/draft-ietf-pkix-eai-addresses-00.txt

I don't mind which approach is used, as long as the problem is solved.

> Another related but distinct area of work would be handling the discrepancy between mail providers treating email addresses as case insensitive (and is acknowledged in RFC5321) yet is required by RFC5280.  Moreover some email providers have other complicated normalization rules e.g. Gmail.  We don't have a draft for this topic but could write something up.

Are you thinking about expressing normalization rules in certificates or somewhere else (e.g. in DNS or SMTP)?

>> and if a short session is needed that can be arranged.

This might be a good idea.

---

From: Peter Bowen <[email-masked]>
Date: Sat, 6 Feb 2016 09:18:21 -0800

> have a draft for this topic but could write something up.

I'm not clear how this is related to 5280.  5321 says that the domain
is case insensitive but the local-part is case sensitive (with the
special exception of "postmaster").

So the following are all different addresses:

[email-masked]
[email-masked]
[email-masked]
[email-masked]

Some email providers may choose to deliver all of those to the same
user, but that is a local policy issue not something that belongs in a
RFC.

Some email providers may also apply other rules, for example
determining the local user by removing anything that comes after a "-"
or "+" character in the local-part, but again this is all local
policy.

Thanks,
Peter

---

From: Wei Chuang <[email-masked]>
Date: Sun, 7 Feb 2016 09:04:45 -0800

On Sat, Feb 6, 2016 at 9:18 AM, Peter Bowen <[email-masked]> wrote:

> discrepancy

I believe there RFC5321 in the context of mail delivery, says SMTP must
preserve the case for interoperability.  However in the same RFC5321 in
Section 2.3.11 interpretation of the email address is left to the
end-points.  Quoting: "Consequently, and due to a long history of problems
when intermediate hosts have attempted to optimize transport by modifying
them, the local-part MUST be interpreted and assigned semantics only by the
host specified in the domain part of the address." In section 4.1.2. it is
more explicit, and says "While the above definition for Local-part is
relatively permissive, for maximum interoperability, a host that expects to
receive mail SHOULD avoid defining mailboxes where the Local-part requires
(or uses) the Quoted-string form or where the Local-part is case-sensitive."

> user, but that is a local policy issue not something that belongs in a

Unless it breaks interoperability, and prevents deployment of RFC5280,
which is problematic as I think we all agree PKI provides significant
improvement in security.

> or "+" character in the local-part, but again this is all local

Agreed that's another thorny problem too.

> Peter

The IETF community has a history of reconciling specification to deployment
practices (e.g. email and the X821 and X822 RFCs).  I'm hoping that in this
case, the PKIX community can find a solution to this too.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Sun, 7 Feb 2016 10:04:51 -0800

On Sun, Feb 7, 2016 at 9:04 AM, Wei Chuang <[email-masked]> wrote:

> end-points.  Quoting: "Consequently, and due to a long history of
> problems when intermediate hosts have attempted to optimize transport by
> modifying them, the local-part MUST be interpreted and assigned semantics
> only by the host specified in the domain part of the address." In section
> 4.1.2. it is more explicit, and says "While the above definition for
> Local-part is relatively permissive, for maximum interoperability, a host
> that expects to receive mail SHOULD avoid defining mailboxes where the
> Local-part requires (or uses) the Quoted-string form or where the
> Local-part is case-sensitive."
>
>>
Its probably also worth calling out what some of the alternatives are for
implementers using existing RFC.  One of which would be to issue multiple
rfc822Name SANs for each possible combination but this would increase
significantly the certificate storage cost and validation time.  As noted
below, it isn't just case, but also potentially '+' or '-' and other
practices.  Another would be to issue a certificate for each address usage,
though there deployment issues.

-Wei

> The IETF community has a history of reconciling specification to
> deployment practices (e.g. email and the X821 and X822 RFCs).  I'm hoping
> that in this case, the PKIX community can find a solution to this too.
>
> -Wei
>
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 8 Feb 2016 14:24:54 +0000

> 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 [email-masked] or [email-masked] or [email-masked] or [email-masked] or [email-masked] 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

---

From: Wei Chuang <[email-masked]>
Date: Tue, 9 Feb 2016 05:57:56 -0800

On Mon, Feb 8, 2016 at 6:24 AM, Miller, Timothy J. <[email-masked]>
wrote:

> 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
> [email-masked] or [email-masked] or [email-masked] or [email-masked] or [email-masked]
> 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).
>

Thank you for writing that up, as that really motivates the problem.

>
> 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?
>

A possibility is that the cert or rather the rfc822Names SAN is already
tied to a domain, and the rules of that domain would apply.

>
> 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.
>

Yeah but that small population of S/MIME users do really care.  And if we
want to expand the population that could use S/MIME beyond that tiny
population of aficionados, then things like this need to be fixed.

>
> 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.
>
Yeah but it's a cop out to UI/UX and is confusing to the user.  When the
users sees a mail that the signature validation failed, they'll assume the
worse when it really was just a mismatching cert name vs FROM/SENDER due to
case or the '+'/'-'.  If the user hasn't already given up on that MUA, very
quickly the user will start discounting what the message signature
validation result means which I think is not what we want.

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
>

-Wei

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Feb 2016 15:04:32 +0100

On 2/8/16 3:24 PM, Miller, Timothy J. wrote:
> 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]. ;)

And to go one further, if they don't implement that advice, what makes
us think they'll implement any other advice?

Eliot

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 9 Feb 2016 14:37:55 +0000

> A possibility is that the cert or rather the rfc822Names SAN is already tied to a
> domain, and the rules of that domain would apply.

There are no "rules for the domain."  My own domain uses just about every MUA under the sun (I know people using *pine*, fergadsake), each of which has a unique S/MIME cert matching semantics.  

> population of aficionados, then things like this need to be fixed.

They care, but they don't matter.  Yes, it's easy to get implementations into OSS projects, but only if you contribute code.  Commercial software requires a business case.  The US DoD had to fight with MS for a couple years to get SupressNameChecks implemented in Outlook/Win, and it *still* isn't implemented right in OWA nor is it in Outlook/Mac.

> Yeah but it's a cop out to UI/UX and is confusing to the user.  When the users
> sees a mail that the signature validation failed, they'll assume the worse
> when it really was just a mismatching cert name vs FROM/SENDER due to
> quickly the user will start discounting what the message signature validation
> result means which I think is not what we want.

First, it's not a cop out if it's the only viable way to make it work.  

Second, S/MIME itself is "confusing to the user."  That's well documented in the numerous "Johnny" papers.

Third, UI/UX is an implementation issue not a standards issue.  Outlook/Win, frex., does not display a failed signature check when SupressNameChecks is enabled; instead it displays the signature as valid but explicitly displays the signer's rfc822Name in the message address block.  This works and experience in the field backs it up.  An application that supports alternative processing when a name match fails (IAW RFC 3750) but still shows a failed signature in the UI is bugged and needs fixing.

This thread should move to [email-masked]; this is not a PKIX issue.  Cert matching semantics in email does not need changes to existing certificate formats or extensions.

-- T

---

From: Wei Chuang <[email-masked]>
Date: Tue, 9 Feb 2016 06:53:56 -0800

> us think they'll implement any other advice?
A specification allows a starting point for a conversation amongst the
implementers, and between the implementers and the CAs. Without one, well
as its been pointed out, adoption of S/MIME has been poor.  In another
thread on the IETF mailing list, folks are lamenting that there hasn't been
much progress with email encryption.  Well issues like this lack of
specification which leads to poor user experience with encrypted emails are
some of the root causes.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Tue, 9 Feb 2016 07:36:49 -0800

On Tue, Feb 9, 2016 at 6:37 AM, Miller, Timothy J. <[email-masked]>
wrote:

> tied to a
> There are no "rules for the domain."  My own domain uses just about every
> MUA under the sun (I know people using *pine*, fergadsake), each of which
> has a unique S/MIME cert matching semantics.
>
> They care, but they don't matter.  Yes, it's easy to get implementations
> into OSS projects, but only if you contribute code.  Commercial software
> requires a business case.  The US DoD had to fight with MS for a couple
> years to get SupressNameChecks implemented in Outlook/Win, and it *still*
> isn't implemented right in OWA nor is it in Outlook/Mac.
>
> users
> validation
> Third, UI/UX is an implementation issue not a standards issue.
> Outlook/Win, frex., does not display a failed signature check when
> SupressNameChecks is enabled; instead it displays the signature as valid
> but explicitly displays the signer's rfc822Name in the message address
> block.  This works and experience in the field backs it up.  An application
> that supports alternative processing when a name match fails (IAW RFC 3750)
> but still shows a failed signature in the UI is bugged and needs fixing.
>
> This thread should move to [email-masked]; this is not a PKIX issue.
> Cert matching semantics in email does not need changes to existing
> certificate formats or extensions.
>

Alright.  I think we'll agree that this part of the conversation is
starting to rathole (though I very much appreciate the anecdotes you've
provided above).  I just was trying to point out an area of potential work
for a working group with regards to letter casing and as pointed out later
'+' and '-' suffixes in email SAN causing RFC5280 validation problems.  It
sounds like I'm just one of many that have asked about this.

-Wei

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 9 Feb 2016 15:52:00 +0000

> Alright.  I think we'll agree that this part of the conversation is starting to
> rathole (though I very much appreciate the anecdotes you've provided
> above).  I just was trying to point out an area of potential work for a working
> group with regards to letter casing and as pointed out later '+' and '-' suffixes
> in email SAN causing RFC5280 validation problems.  It sounds like I'm just one
> of many that have asked about this.

I think if there's work to be done it's work that would have to revive S/MIME.  For example, an S/MIME signature could flag name matching semantics, e.g. by adding a new attribute BOOLEAN for case-sensitivity and including it in SignerInfo as a signed attribute in CMS, along with a processing spec in Cert Handling.

Nothing in that touches a cert.

-- T

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Feb 2016 20:00:51 +0000

Hiya,

On 09/02/16 15:52, Miller, Timothy J. wrote:
> I think if there's work to be done it's work that would have to revive S/MIME. 

Just because we have had pkix and smime WGs in the past does not mean
that we need to organise that way in future. Note that I'm not arguing
against the main conclusion above, but only against the "would have to."

Cheers,
S.

PS: FWIW - if I ruled the world the only new e2e email security WG I'd
want would be the grand unification (or replacement) of PGP/SMIME WG.
But I don't rule the world, so that's not the plan :-)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 9 Feb 2016 15:36:58 -0500

> against the main conclusion above, but only against the "would have to."

I think one group looking at both would be ideal. Most of the work
that hasn't been done already tends to be of the 'making X work with
Y' type.

The biggest problem in S/MIME right now is how do you tell potential
senders what they should do. And your communication channel is
limited to the contents of the cert.

Cryptographic protocols need a maintenance WG. But there isn't really
enough work for two full WGs and each WG is load on the secretariat,
chairs, everything. So joining the two seems to make perfect sense to
me. On top of that, if it is one WG that cuts the risk of a meeting
clash during IETFs.

The technical work Russ has proposed is needed for S/MIME is probably
not enough for a full WG either. But it is WG type work.

> But I don't rule the world, so that's not the plan :-)

Accepted but noting your weasel word 'only'.

Since I am working on precisely that problem, I know that any
deployment will have to be phased and have a transition plan for
OpenPGP and for S/MIME. And it will have to meet all the use cases of
both. So having WGs that can interact with the successor protocol is a
positive as far as I am concerned.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 9 Feb 2016 20:47:13 +0000

> senders what they should do. And your communication channel is limited to
> the contents of the cert.

I disagree.  The defacto standard for cert discovery and crypto capability discovery in S/MIME is an exchange of signed emails.  That being so, the communication channel is not limited to the cert, the channel includes the signed email itself.  As I posted in the fork of this thread I moved to the old S/MIME WG list (which is still working), it would be trivial to define a name-matching indicator OID and add it as a SignedAttribute in SignerInfo, with a concomitant update to 5750 to describe the algorithms associated with the OID.

Note that the most prevalent way to discover crypto capabilities and certs outside of an exchange of emails is to *put a blank signed email in a directory* (userSMIMECertificate).  So email is still the signal path.

-- T

---

From: Wei Chuang <[email-masked]>
Date: Wed, 10 Feb 2016 07:08:03 -0800

> against the main conclusion above, but only against the "would have to."

Just wanted to put in an opinion that we (as in the co-authors of
http://www.ietf.org/id/draft-lbaudoin-iemax-02.txt) think there's work to
be done with S/MIME as well and a +1 for reviving a WG.  It could help
solve issues like the previously mentioned key discovery problem, header
privacy and maintenance updates.  We're less certain of what that WG
structure ought to be but certainly supportive either way.

-Wei

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Feb 2016 10:46:26 -0500

I don't think using a signed attribute in the CMS is a good idea for two 
reasons:

1) The matching rules would need to be based on the host domain's rules 
(e.g., does it consider Example1@... and example1@... to refer to the 
same mailbox). It is not the sender's MUA that matters.

2) If a host domain treats the local part as case sensitive (e.g., 
Example1 and example1 refer to different mailboxes), it shouldn't be 
possible for the sender to get the recipient to perform a case 
insensitive match.

So, it seems to me that if an attribute is to be created to include in 
an email to indicate to the recipient the rules the sender's domain's 
name matching semantics, it should be an attribute that is created and 
signed by the domain, not the individual sender.

Could DKIM be used for this?

Dave

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Feb 2016 17:06:51 +0100

> Could DKIM be used for this?

Are you proposing that local parts go into the DNS or that DNS be used
as a signaling mechanism as to whether local parts are case sensitive?

Eliot

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Feb 2016 11:35:40 -0500

No. The following appeared in the body
of the email that you just sent:

DKIM-Signature: v=1; a=rsa-sha256;
c=relaxed/simple;

d=cisco.com; i=@cisco.com; l=1169; q=dns/txt;
s=iport;

t=1455120414; x=1456330014;

h=subject:to:references:cc:from:message-id:date:

mime-version:in-reply-to;

bh=ek/ye425aJM8CS9AGNRcr750NuBltwGL4xXur0BHO7U=;

b=GQWh7w1KuT0aK18aTnJIwNOfdpi9IcqrKs7reiA0y4UJQ7dLfRQwb19X

WX/qctUW2HAF081jJzJYH6H9J44JrcR6CpYhukLiBcM+ndYxbgKHZZgsX

blg2bVMAkoNMF/RK/OGYKRmXCrk7LLP2DimVWXmbeZtpcGxjUafaxsXXD

U=;

I not a DKIM expert, but my guess is that the "h=..." field is
indicating that the above signature covers the subject, to,
references, cc, from, message-id, data, mime-version, and
in-reply-to fields in the email's header.

I was just wondering whether a new field could be added to the
email headers that specifies the mail server's email address
matching rules, and have this header be covered by the DKIM
signature.

As I understand it, the public key needed to verify the signature
above is found in DNS, but I wasn't suggesting adding anything new
to DNS, just to the headers of email messages.

Dave

On 02/10/2016 11:06 AM, Eliot Lear wrote:

Eliot

On 02/10/2016 10:46 AM, David A. Cooper
wrote:

I don't
think using a signed attribute in the CMS is a good idea for two
reasons:

1) The matching rules would need to be based on the host domain's
rules (e.g., does it consider Example1@... and example1@... to
refer to the same mailbox). It is not the sender's MUA that
matters.

2) If a host domain treats the local part as case sensitive (e.g.,
Example1 and example1 refer to different mailboxes), it shouldn't
be possible for the sender to get the recipient to perform a case
insensitive match.

So, it seems to me that if an attribute is to be created to
include in an email to indicate to the recipient the rules the
sender's domain's name matching semantics, it should be an
attribute that is created and signed by the domain, not the
individual sender.

Dave

Alright.  I think we'll agree that this
part of the conversation is starting to

rathole (though I very much appreciate the anecdotes you've
provided

above).  I just was trying to point out an area of potential
work for a working

group with regards to letter casing and as pointed out later
'+' and '-' suffixes

in email SAN causing RFC5280 validation problems.  It sounds
like I'm just one

I think if there's work to be done it's work that would have to
revive S/MIME.  For example, an S/MIME signature could flag name
matching semantics, e.g. by adding a new attribute BOOLEAN for
case-sensitivity and including it in SignerInfo as a signed
attribute in CMS, along with a processing spec in Cert Handling.

-- T

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Feb 2016 18:16:17 +0100

Hi David,

On 2/10/16 5:35 PM, David A. Cooper wrote:
> No. The following appeared in the body of the email that you just sent:
>
>     DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
>       d=cisco.com; i=@cisco.com; l=1169; q=dns/txt; s=iport;
> references, cc, from, message-id, data, mime-version, and in-reply-to
> fields in the email's header.

Correct.
>
> I was just wondering whether a new field could be added to the email
> headers that specifies the mail server's email address matching rules,
> and have this header be covered by the DKIM signature.

Ah!  The only issue is that a DKIM signature is that of the domain owner
"e.g., cisco.com" whereas the certificate is bound to an individual. 
Thus the trust models do not perfectly align.  And so one has to look at
whether there are attacks that can be effected by such a header
insertion (I haven't).

Eliot

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Feb 2016 13:22:28 -0500

I don't understand the issue. The
purpose of the attribute would be for the domain owner to indicate
to others whether it treats the local part of email addresses as
case sensitive or case insensitive. So it would be the domain
owner providing information about itself.

Yes, the recipient would be using the information provided by the
domain owner in the header to determine how to compare the email
address in the "From" line with the email address in the
certificate, but I don't think it matters that the information
comes from different sources. The domain owner is authoritative
for the matching rules it uses, and if the CA puts the wrong email
address in the certificate, then that is already a problem. The
recipient knowing the domain owner's email address matching rules
doesn't make that worse.

Dave

On 02/10/2016 12:16 PM, Eliot Lear wrote:

Hi David,

On 2/10/16 5:35 PM, David A. Cooper
wrote:

No. The following appeared in the
body of the email that you just sent:

d=cisco.com; i=@cisco.com; l=1169;
q=dns/txt; s=iport;

U=;

Correct.

Ah!  The only issue is that a DKIM signature is that of the domain
owner "e.g., cisco.com" whereas the certificate is bound to an
individual.  Thus the trust models do not perfectly align.  And so
one has to look at whether there are attacks that can be effected
by such a header insertion (I haven't).

Eliot

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 10 Feb 2016 18:49:03 +0000

> I don't understand the issue. The purpose of the attribute would be for the
> domain owner to indicate to others whether it treats the local part of email
> addresses as case sensitive or case insensitive. So it would be the domain

Stop.  There is no domain policy.  Name matching is a *per MUA* issue.  An organization may choose to deploy a common MUA--and may even enforce its use--but that won't work for any shared service models (e.g., Gmail). 

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 10 Feb 2016 19:03:55 +0000

> (e.g., does it consider Example1@... and example1@... to refer to the same
> mailbox). It is not the sender's MUA that matters.

The domain doesn't set squat.  The domain owner may have a mail system that's case sensitive or case insensitive, but it doesn't matter because mail servers don't process S/MIME messages.  Only MUAs (which include webmail services) process S/MIME.  

-- T

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Feb 2016 14:05:24 -0500

In what way is name matching a per MUA issue? It is the NIST mail server 
(or actually the server of service provider that handles mail for NIST) 
that decides that "[email-masked]" and "[email-masked]" 
refer to the same mailbox. You can send an email to either address and 
it will be delivered to the same mailbox because the server choses to do 
so.  Neither my nor your choice of mail client has any effect on that.

If someone receives a signed email with a "From" line of 
"[email-masked]" and a certificate with a subjectAltName of 
"[email-masked]," they want to know whether 
"[email-masked]" and "[email-masked]" refer to the same 
mailbox, and the answer to that has everything to do with the NIST mail 
server and has nothing whatsoever to do with anyone choice of MUA.

---

From: Peter Bowen <[email-masked]>
Date: Wed, 10 Feb 2016 11:43:54 -0800

On Wed, Feb 10, 2016 at 11:05 AM, David A. Cooper <[email-masked]> wrote:
> In what way is name matching a per MUA issue? It is the NIST mail server (or
> actually the server of service provider that handles mail for NIST) that
> decides that "[email-masked]" and "[email-masked]" refer to
> the same mailbox. You can send an email to either address and it will be
> delivered to the same mailbox because the server choses to do so.  Neither
> my nor your choice of mail client has any effect on that.
>
> "[email-masked]," they want to know whether "[email-masked]"
> and "[email-masked]" refer to the same mailbox, and the answer to
> that has everything to do with the NIST mail server and has nothing
> whatsoever to do with anyone choice of MUA.

This is only the simplest case.  Things get a lot more complex from
here.  A single mailbox may have infinite addresses, many of which may
not be discoverable.  Some providers use this as a privacy features.

A few examples:
- [email-masked], [email-masked], and
[email-masked] all deliver to the same mailbox.
- The same is true for [email-masked] and [email-masked].
- [email-masked], [email-masked] and
[email-masked] also all deliver to the same mailbox.

However this points out a real privacyrisk -- I may not want people
knowing that m8r-cfbm1 and anonmouse are the same person.  Obviously
the mailbox provider knows, but why should a sender know?

Thanks,
Peter

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 Feb 2016 14:54:59 -0500

Some mail systems do case folding, but others do not.  RFC 822 says that the left-hand side is case sensitive.

Russ

On Feb 10, 2016, at 2:05 PM, David A. Cooper wrote:

> In what way is name matching a per MUA issue? It is the NIST mail server (or actually the server of service provider that handles mail for NIST) that decides that "[email-masked]" and "[email-masked]" refer to the same mailbox. You can send an email to either address and it will be delivered to the same mailbox because the server choses to do so.  Neither my nor your choice of mail client has any effect on that.
> 
> If someone receives a signed email with a "From" line of "[email-masked]" and a certificate with a subjectAltName of "[email-masked]," they want to know whether "[email-masked]" and "[email-masked]" refer to the same mailbox, and the answer to that has everything to do with the NIST mail server and has nothing whatsoever to do with anyone choice of MUA.
>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Feb 2016 15:29:31 -0500

I agree that that what I'm suggesting
couldn't be used to indicate all of the email addresses that
resolve to the same mailbox. In addition to the NIST mail server
treating the local part as case insensitive, there are other
aliases that resolve to my mailbox other than 'david.cooper'.

This whole conversation arose since RFC 5280 says:

Two email addresses are considered to match if:

1)  the local-part of each name is an exact match, AND

2)  the host-part of each name matches using a
case-insensitive ASCII comparison.

whereas RFC 5321 says:

The local-part of a mailbox MUST BE treated as case
sensitive. Therefore, SMTP implementations MUST take care to
preserve the case of mailbox local-parts.  In particular, for some hosts,
the user "smith" is different from the user "Smith". However,
exploiting the case sensitivity of mailbox local-parts impedes
interoperability and is discouraged.  Mailbox domains
follow normal DNS rules and are hence not case sensitive.

Since hosts are allowed to treat the local-parts in a case
sensitive manner, and there is no way at the moment for the
recipient of a signed email (or the sender of an encrypted email)
to know whether the sender's host (or recipient's host) treats the
local-parts in a case sensitive manner, RFC 5280 takes the
conservative approach and requires matching to be performed in a
case sensitive manner (just as RFC 5321 requires SMTP
implementation to preserve case).

It has been pointed out that this creates problems since most
hosts treat local-parts are case insensitive and it is not
uncommon for there to be a case mismatch between the "From" line
and the email address in the certificate. Most email clients deal
with this by ignoring RFC 5280 and performing a case insensitive
match, which isn't a problem in the vast majority of cases in
which the host corresponding to the email address treats the
local-parts in a case insensitive manner, but would be in the case
of hosts that treat local-parts in a case sensitive manner (my
mail client shouldn't consider it acceptable for an email with a
"From" line of "[email-masked]" to be signed using a
certificate with a subjectAltName of "[email-masked]" if
[email-masked] and [email-masked] are different users).

So, some people have suggested that it would be nice if there was
a way for S/MIME clients to be able to discover whether a host
treats the local-parts of email addresses in its domain in a case
sensitive or case insensitive manner, so that the S/MIME client
can know whether it can safely perform a case insensitive match of
"From" line and certificate contents or if it should perform a
case sensitive match.

I was merely suggesting a possible way to convey that information
to S/MIME clients in a secure manner, if there is agreement that
it is worthwhile to make such information available.

Anything beyond simple, generic matching rules that apply to all
of a hosts mailboxes (e.g., the host treats local-parts in a case
insensitive manner) could only be handled by including multiple
email addresses in the certificate (e.g., [email-masked] and
[email-masked]).

Dave

On 02/10/2016 02:43 PM, Peter Bowen wrote:

A few examples:

Thanks,
Peter

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Feb 2016 22:14:34 +0100

Hi David,

On 2/10/16 7:22 PM, David A. Cooper wrote:
> I don't understand the issue. The purpose of the attribute would be
> for the domain owner to indicate to others whether it treats the local
> part of email addresses as case sensitive or case insensitive. So it
> would be the domain owner providing information about itself.
>
> address in the "From" line with the email address in the certificate,
> but I don't think it matters that the information comes from different
> sources. The domain owner is authoritative for the matching rules it
> uses, and if the CA puts the wrong email address in the certificate,
> then that is already a problem. The recipient knowing the domain
> owner's email address matching rules doesn't make that worse.

I would suggest simply that this analysis be formalized a bit, with all
the actors reviewed, including the sender (MUA), CA, MSA, and then the
recipient.

Also, keep in mind that there are limits to using DKIM in that
signatures are fragile, especially in the face of mailing lists.

On the other hand, I would note that in this area perfect may be the
enemy of good and if we can make things better for some or perhaps many
with little or no cost, then why not do so?

Eliot

---

From: "Tom Gindin" <[email-masked]>
Date: Sat, 13 Feb 2016 21:19:35 -0500

David:

        Does it make sense to define an OTHER-NAME for email addresses 
with a matching rule followed by a UTF8String?  There could be different 
matching rules for different character sets, and a matching rule for 
"case-insensitive IA5, ignore anything from percent to at".  As Russ 
pointed out, it's the domain's MTA that matters in interpreting email 
addresses as destinations, not the MUA, so the matching rule for each 
domain is well-defined.
        Of course, matching rules are open-ended, and the set required for 
full conformance would need to be defined.

Tom Gindin
P.S.    The above suggestion is mine, and not that of my employer.

From:   "David A. Cooper" <[email-masked]>
To:     Peter Bowen <[email-masked]>
Cc:     pkix <[email-masked]>
Date:   02/10/2016 03:30 PM
Subject:        Re: [pkix] Email address matching rules (was Re: Is it 
time for a pkix extensions (or similar) wg?)
Sent by:        "pkix" <[email-masked]>

I agree that that what I'm suggesting couldn't be used to indicate all of 
the email addresses that resolve to the same mailbox. In addition to the 
NIST mail server treating the local part as case insensitive, there are 
other aliases that resolve to my mailbox other than 'david.cooper'.

  2)  the host-part of each name matches using a case-insensitive ASCII 
comparison.
whereas RFC 5321 says:
The local-part of a mailbox MUST BE treated as case sensitive. Therefore, 
SMTP implementations MUST take care to preserve the case of mailbox 
local-parts.  In particular, for some hosts, the user "smith" is different 
from the user "Smith". However, exploiting the case sensitivity of mailbox 
local-parts impedes interoperability and is discouraged.  Mailbox domains 
follow normal DNS rules and are hence not case sensitive.

Since hosts are allowed to treat the local-parts in a case sensitive 
manner, and there is no way at the moment for the recipient of a signed 
email (or the sender of an encrypted email) to know whether the sender's 
host (or recipient's host) treats the local-parts in a case sensitive 
manner, RFC 5280 takes the conservative approach and requires matching to 
be performed in a case sensitive manner (just as RFC 5321 requires SMTP 
implementation to preserve case).

It has been pointed out that this creates problems since most hosts treat 
local-parts are case insensitive and it is not uncommon for there to be a 
case mismatch between the "From" line and the email address in the 
certificate. Most email clients deal with this by ignoring RFC 5280 and 
performing a case insensitive match, which isn't a problem in the vast 
majority of cases in which the host corresponding to the email address 
treats the local-parts in a case insensitive manner, but would be in the 
case of hosts that treat local-parts in a case sensitive manner (my mail 
client shouldn't consider it acceptable for an email with a "From" line of 
"[email-masked]" to be signed using a certificate with a subjectAltName 
of "[email-masked]" if [email-masked] and [email-masked] are 
different users).

So, some people have suggested that it would be nice if there was a way 
for S/MIME clients to be able to discover whether a host treats the 
local-parts of email addresses in its domain in a case sensitive or case 
insensitive manner, so that the S/MIME client can know whether it can 
safely perform a case insensitive match of "From" line and certificate 
contents or if it should perform a case sensitive match.

I was merely suggesting a possible way to convey that information to 
S/MIME clients in a secure manner, if there is agreement that it is 
worthwhile to make such information available.

Anything beyond simple, generic matching rules that apply to all of a 
hosts mailboxes (e.g., the host treats local-parts in a case insensitive 
manner) could only be handled by including multiple email addresses in the 
certificate (e.g., [email-masked] and [email-masked]).

Dave

On 02/10/2016 02:43 PM, Peter Bowen wrote:
On Wed, Feb 10, 2016 at 11:05 AM, David A. Cooper <[email-masked]> 
wrote:

(or

A few examples:

Thanks,
Peter

---

From: "Tom Gindin" <[email-masked]>
Date: Sun, 14 Feb 2016 21:32:41 -0500

I think the MUD syntax part of your draft's section 2 would be 
more typical in PKIX, and no less clear, if it looked like this:
The MUD URI is a non-critical Certificate extension that points
 to an on-line Manufacturer Usage Description concerning the certificate 
subject.  This extension contains a single Uniform Resource Identifier 
(URI).  Internationalized Resource Identifiers must be represented as 
URI's in the way described in RFC 5280, section 7.4.  The semantics of the 
URI are defined in [I-D.lear-ietf-netmod-mud].
 
   id-pe-mudURI OBJECT IDENTIFIER ::= { id-pe TBD }

   MudURISyntax ::= { IA5String }

Tom Gindin
P.S.    The opinions above are mine, and not necessarily those of my 
employer

From:   Eliot Lear <[email-masked]>
To:     Stephen Farrell <[email-masked]>, [email-masked]
Date:   02/05/2016 07:17 AM
Subject:        Re: [pkix] [saag] Fwd: Is it time for a pkix extensions 
(or similar) wg?
Sent by:        "pkix" <[email-masked]>

Eliot

[attachment "signature.asc" deleted by Tom Gindin/Watson/IBM] 
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Wei Chuang <[email-masked]>
Date: Fri, 19 Feb 2016 21:52:52 -0800

Tom: I agree with the approach to use OTHER-NAMES but wonder if a simple
case matching rule adequately covers all possible casing possibilities for
foreign
languages.  An example I'm told is lower case German 'ß' <-> may become
'SS' but also 'ẞ' and this interepretation has been recently changing as
well.
I just wanted to put out probably the another solution which is some sort
of limited
regular expression language.  This adds a fair amount of complexity, and the
main justification would be that it could better support international
alphabets
have more complicated letter casing situations than IA5 that we're familiar
with
and some of these may be difficult to anticipate.  Regular expression could
better support also the '+' and '-' scenarios as well.

Eliot: Here's a first cut at an analysis of these naming features:

Parties:
Alice: Wants to send a signed message to Bob.
Bob: Message recipient of the signed message
Casey: CA authority
Eve: wants to spoof Alice's identity else using past email.
Franklin: wants to spoof Alice's identity by creating a spoofable
certificate
with the CA Casey.
Mallory: wants to MitM the private communication between Bob and Alice

Actions
1) Alice obtain certificate from CA Casey using a CSR
2) Alice emails Bob a signed message
3) Bob validates Alice's signature
4) Bob emails Alice an encrypted message in reply

Attacks
1a) Eve performs a replay attack i.e. spoofing Alice by replaying her
signed email to Bob from
Eve's account.  Eve takes advantage of ambiguity afforded by the new email
naming
scheme either because the specification or the encoded name is overly broad
compared
to the domain practices.
2a) Franklin obtains a certificate from CA Casey crafting a subject name to
allow
spoofing Alice's identity. Like Eve, Franklin uses ambuiguity in the new
naming scheme
to get past whatever ownership check that Casey does on Franklin's account
but unlike Eve
can craft whatever signed message is convenient to Franklin.  Franklin can
then send
this message to Bob who will validate message as coming from spoofed Alice.
2b) Even with existing validation practices Bob might be confused about two
separate
users i.e. alice vs Alice and believe they are the same email address,
which Franklin
could take advantage of.
2c) Similar confusion may be accomplished by using unicode homograph
characters e.g.
ascii 'c' with cryllic 'с'.  This is an issue with supporting
internationalized local-parts email
addresses.
3) Mallory wants to MitM the private communication between Bob and Alice.
Most likely
Mallory uses the same technique as Franklin to create a spoofed
certificate.  When Bob replies
and uses the certificate to communicate privately with spoofed Alice,
Mallory will receive the
reply.  Maloory decrypts and reads the message, and then re-encrypt and
forwards for Alice.

Some mitigations
1) Exact naming that allows for no ambiguity
2) Simple rules to prevent or limit ambiguity
3) CA Casey knows the exact naming rules of Alice's domain to prevent
attack in 2a).
Casey could also apply checks to prevent unicode homograph attacks in case
2c).
4) Bob's provider could use exact naming rules provided in the certificate
to develop
Spam/Phishing models as its now possible to know who exactly Alice is or
isn't.  Attempts to
spoof Alice will be labeled and treated as Phish.

thanks,
-Wei

On Sat, Feb 13, 2016 at 6:19 PM, Tom Gindin <[email-masked]> wrote:

> ------------------------------
>
>
>
> *"[email-masked]"* <[email-masked]>to be signed using a certificate
> with a subjectAltName of *"[email-masked]"* <[email-masked]>if
> [email-masked]* <[email-masked]>and [email-masked]*
> <[email-masked]>are different users).
>
> certificate (e.g., [email-masked]* <[email-masked]>and [email-masked]*
> <[email-masked]>).
>
> Dave
>
> On Wed, Feb 10, 2016 at 11:05 AM, David A. Cooper
> *<[email-masked]>* <[email-masked]>wrote:
>
> decides that *"[email-masked]"* <[email-masked]>and
> *"[email-masked]"* <[email-masked]>refer to
> *"[email-masked]"* <[email-masked]>and a certificate with a
> subjectAltName of
> *"[email-masked],"* <[email-masked],>they want to know
> whether *"[email-masked]"* <[email-masked]>
> and *"[email-masked]"* <[email-masked]>refer to the same
> mailbox, and the answer to
> - [email-masked]* <[email-masked]>, [email-masked]*
> <[email-masked]>, and
> [email-masked]* <[email-masked]>all deliver to the same mailbox.
> - The same is true for [email-masked]* <[email-masked]>and [email-masked]*
> <[email-masked]>.
> - [email-masked]* <[email-masked]>,
> [email-masked]* <[email-masked]>and
> [email-masked]* <[email-masked]>also all deliver to
> the same mailbox.
>

---

From: Russ Housley <[email-masked]>
Date: Sun, 21 Feb 2016 18:40:46 -0500

It seems like we are coming to the conclusion that Section 7 of RFC 5280 no longer correct.

Russ

On Feb 20, 2016, at 12:52 AM, Wei Chuang wrote:

> case matching rule adequately covers all possible casing possibilities for foreign
> 'SS' but also 'ẞ' and this interepretation has been recently changing as well.
> I just wanted to put out probably the another solution which is some sort of limited
> main justification would be that it could better support international alphabets
> have more complicated letter casing situations than IA5 that we're familiar with
> Franklin: wants to spoof Alice's identity by creating a spoofable certificate
> with the CA Casey.
> 1a) Eve performs a replay attack i.e. spoofing Alice by replaying her signed email to Bob from
> Eve's account.  Eve takes advantage of ambiguity afforded by the new email naming
> sch eme either because the specification or the encoded name is overly broad compared
> to the domain practices.
> 2a) Franklin obtains a certificate from CA Casey crafting a subject name to allow
> spoofing Alice's identity. Like Eve, Franklin uses ambuiguity in the new naming scheme
> to get past whatever ownership check that Casey does on Franklin's account but unlike Eve
> can craft whatever signed message is convenient to Franklin.  Franklin can then send
> 2b) Even with existing validation practices Bob might be confused about two separate
> users i.e. alice vs Alice and believe they are the same email address, which Franklin
> could take advantage of.
> 2c) Similar confusion may be accomplished by using unicode homograph characters e.g.
> ascii 'c' with cryllic 'с'.  This is an issue with supporting internationalized local-parts email
> addresses.
> 3) Mallory wants to MitM the private communication between Bob and Alice.  Most likely
> Mallory uses the same technique as Franklin to create a spoofed certificate.  When Bob replies 
> and uses the certificate to communicate privately with spoofed Alice, Mallory will receive the
> reply.  Maloory decrypts and reads the message, and then re-encrypt and forwards for Alice.
> 
> Some mitigations
> 3) CA Casey knows the exact naming rules of Alice's domain to prevent attack in 2a).
> Casey could also apply checks to prevent unicode homograph attacks in case 2c).
> 4) Bob's provider could use exact naming rules provided in the certificate to develop
> Spam/Phishing models as its now possible to know who exactly Alice is or isn't.  Attempts to
>         Does it make sense to define an OTHER-NAME for email addresses with a matching rule followed by a UTF8String?  There could be different matching rules for different character sets, and a matching rule for "case-insensitive IA5, ignore anything from percent to at".  As Russ pointed out, it's the domain's MTA that matters in interpreting email addresses as destinations, not the MUA, so the matching rule for each domain is well-defined.
>         Of course, matching rules are open-ended, and the set required for full conformance would need to be defined.
> 
> Tom Gindin
> Subject:        Re: [pkix] Email address matching rules (was Re: Is it time for a pkix extensions (or similar) wg?)
> I agree that that what I'm suggesting couldn't be used to indicate all of the email addresses that resolve to the same mailbox. In addition to the NIST mail server treating the local part as case insensitive, there are other aliases that resolve to my mailbox other than 'david.cooper'.
> 
>   2)  the host-part of each name matches using a case-insensitive ASCII comparison.
> whereas RFC 5321 says:
> The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts.  In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.  Mailbox domains follow normal DNS rules and are hence not case sensitive.
> 
> Since hosts are allowed to treat the local-parts in a case sensitive manner, and there is no way at the moment for the recipient of a signed email (or the sender of an encrypted email) to know whether the sender's host (or recipient's host) treats the local-parts in a case sensitive manner, RFC 5280 takes the conservative approach and requires matching to be performed in a case sensitive manner (just as RFC 5321 requires SMTP implementation to preserve case).
> 
> It has been pointed out that this creates problems since most hosts treat local-parts are case insensitive and it is not uncommon for there to be a case mismatch between the "From" line and the email address in the certificate. Most email clients deal with this by ignoring RFC 5280 and performing a case insensitive match, which isn't a problem in the vast majority of cases in which the host corresponding to the email address treats the local-parts in a case insensitive manner, but would be in the case of hosts that treat local-parts in a case sensitive manner (my mail client shouldn't consider it acceptable for an email with a "From" line of "[email-masked]"to be signed using a certificate with a subjectAltName of "[email-masked]"if [email-masked] [email-masked] different users).
> 
> So, some people have suggested that it would be nice if there was a way for S/MIME clients to be able to discover whether a host treats the local-parts of email addresses in its domain in a case sensitive or case insensitive manner, so that the S/MIME client can know whether it can safely perform a case insensitive match of "From" line and certificate contents or if it should perform a case sensitive match.
> 
> I was merely suggesting a possible way to convey that information to S/MIME clients in a secure manner, if there is agreement that it is worthwhile to make such information available.
> 
> Anything beyond simple, generic matching rules that apply to all of a hosts mailboxes (e.g., the host treats local-parts in a case insensitive manner) could only be handled by including multiple email addresses in the certificate (e.g., [email-masked] [email-masked]).
> 
> Dave
> 
> On Wed, Feb 10, 2016 at 11:05 AM, David A. Cooper <[email-masked]>wrote:
> 
> decides that "[email-masked]"and "[email-masked]"refer to
> "[email-masked]"and a certificate with a subjectAltName of
> "[email-masked],"they want to know whether "[email-masked]"
> and "[email-masked]"refer to the same mailbox, and the answer to
> [email-masked] deliver to the same mailbox.
> - The same is true for [email-masked] [email-masked].
> - [email-masked], [email-masked]
> [email-masked] all deliver to the same mailbox.
> 
> https ://www.ietf.org/mailman/listinfo/pkix
> 
> 
> 
>

---

From: "Tom Gindin" <[email-masked]>
Date: Sun, 21 Feb 2016 21:23:12 -0500

Wei:

        I am NOT proposing that only matching rules that apply to all 
known languages be used, since it may well not be feasible for such rules 
to be written and implemented.  Likewise, I am not proposing that 
parameterized matching rules be used (and a regular expression is a quite 
open-ended parameter).  This is particularly the case since the matching 
rule has to be included in the certificate, and minor upgrades to a 
regular expression can't be made during the lifetime of the certificate. 
The German character you mentioned is not part of IA5 or ASCII, although 
it's part of Latin-1.
        It doesn't seem like a critical issue whether an email matching 
rule for Latin alphabet addresses maps Devanagari or Oriya digits to ASCII 
ones or not, although it certainly matters when the email address is in 
those scripts.  I may be thought biased, because I did propose the 
"collapse hyphens and ignore case" rule for account identifiers during the 
development of RFC 4043, which was rejected on the grounds that although 
that rule made sense for a few major scripts it had no equivalent outside 
them.

Tom Gindin, CISSP

From:   Wei Chuang <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, Eliot Lear <[email-masked]>
Cc:     "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Date:   02/20/2016 12:52 AM
Subject:        Re: [pkix] Email address matching rules (was Re: Is it 
time for a pkix extensions (or similar) wg?)

Tom: I agree with the approach to use OTHER-NAMES but wonder if a simple
case matching rule adequately covers all possible casing possibilities for 
foreign
languages.  An example I'm told is lower case German 'ß' <-> may become
'SS' but also '?' and this interepretation has been recently changing as 
well.
I just wanted to put out probably the another solution which is some sort 
of limited
regular expression language.  This adds a fair amount of complexity, and 
the
main justification would be that it could better support international 
alphabets
have more complicated letter casing situations than IA5 that we're 
familiar with
and some of these may be difficult to anticipate.  Regular expression 
could
better support also the '+' and '-' scenarios as well.

Eliot: Here's a first cut at! an analysis of these naming features:

Parties:

Actions

Attacks
1a) Eve performs a replay attack i.e. spoofing Alice by replaying her 
signed email to Bob from
Eve's account.  Eve takes advantage of ambiguity afforded by the new email 
naming
sc! heme either because the specification or the encoded name is overly 
broad compared
to the domain practices.
2a) Franklin obtains a certificate from CA Casey crafting a subject name 
to allow
spoofing Alice's identity. Like Eve, Franklin uses ambuiguity in the new 
naming scheme
to get past whatever ownership check that Casey does on Franklin's account 
but unlike Eve
can craft whatever signed message is convenient to Franklin.  Franklin can 
then send
this message to Bob who will validate message as coming from spoofed 
Alice.
2b) Even with existing validation practices Bob might be confused about 
two separate
users i.e. alice vs Alice and believe they are the same email address, 
which Franklin
could take advantage of.
2c) Similar confusion may be accomplished by using unicode homograph 
characters e.g.
ascii 'c' with cryllic 'с'.  This is an issue! with supporting 
internationalized local-parts email
addresses.
3) Mallory wants to MitM the private communication between Bob and Alice.  
Most likely
Mallory uses the same technique as Franklin to create a spoofed 
certificate.  When Bob replies 
and uses the certificate to communicate privately with spoofed Alice, 
Mallory will receive the
reply.  Maloory decrypts and reads the message, and then re-encrypt and 
forwards for Alice.

Some mitigations
Spam/Phishing models as its now possible to know wh! o exactly Alice is or 

thanks,
-Wei

Tom Gindin

"[email-masked]"to be signed using a certificate with a subjectAltName 
of "[email-masked]"if [email-masked] [email-masked] 
different users).

Anything beyond simple, generic matching rules that apply to all of a 
hosts mailboxes (e.g., the host treats local-parts in a case insensitive 
manner) could only be handled by including multiple email addresses in the 
certificate (e.g., [email-masked] [email-masked]).

Dave

A few examples:

Thanks,
Peter

_______________________________________________
pkix mailing list
[email-masked]
http! s://www.ietf.org/mailman/listinfo/pkix

---

From: Wei Chuang <[email-masked]>
Date: Mon, 22 Feb 2016 10:47:51 -0800

> It seems like we are coming to the conclusion that Section 7 of RFC 5280

Agreed it would be very helpful to update internationalization support for
RFC5280 particularly for email addresses.

-Wei

>>         Of course, matching rules are open-ended, and the set required
>> for full conformance would need to be defined.
>>
>> Tom Gindin
>> *"[email-masked]"* <[email-masked]>to be signed using a
>> certificate with a subjectAltName of *"[email-masked]"*
>> <[email-masked]>if [email-masked]* <[email-masked]>and
>> [email-masked]* <[email-masked]>are different users).
>>
>> *"[email-masked]"* <[email-masked]>and a certificate with
>> a subjectAltName of
>> - The same is true for [email-masked]* <[email-masked]>and
>> [email-masked]* <[email-masked]>.
>> <https://www.ietf.org/mailman/listinfo/pkix>
>>
>>
>>
>>

---

From: Wei Chuang <[email-masked]>
Date: Mon, 22 Feb 2016 11:02:11 -0800

On Sun, Feb 21, 2016 at 6:23 PM, Tom Gindin <[email-masked]> wrote:

> rule has to be included in the certificate, and minor upgrades to a regular
> expression can't be made during the lifetime of the certificate.  The
> German character you mentioned is not part of IA5 or ASCII, although it's
> part of Latin-1.

Understood.  I should have pointed out earlier that I believe what you
propose will work for the majority of cases, and I'm not sure how
significant these types of corner cases are though they will exist.

> that rule made sense for a few major scripts it had no equivalent outside
Thanks for pointing that out.

-Wei

> On Sat, Feb 13, 2016 at 6:19 PM, Tom Gindin <[email-masked]*
> <[email-masked]>> wrote:
>         David:
>
> From:        "David A. Cooper" <[email-masked]*
> <[email-masked]>>
> To:        Peter Bowen <[email-masked]* <[email-masked]>>
> Cc:        pkix <[email-masked]* <[email-masked]>>
> Sent by:        "pkix" <[email-masked]* <[email-masked]>>
> subjectAltName of*"[email-masked],"* <[email-masked],>they
> want to know whether *"[email-masked]"* <[email-masked]>
> [email-masked]* <[email-masked]>
> *http! s://www.ietf.org/mailman/listinfo/pkix*
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/pkix*