Subject: Algorithm for comparing two email addresses (draft-ietf-smime-3850bis)?

From: Chris Newman <[email-masked]>
Date: Thu, 08 Jan 2009 09:27:14 -0800

When I was reviewing draft-ietf-smime-3850bis, I noticed it mandates 
comparison of email addresses but did not specify the algorithm for doing 
so.

My DISCUSS comment is here: 
<https://datatracker.ietf.org/idtracker/ballot/2906/>

Is anyone aware of a stable reference for the algorithm to compare two 
email addresses (one from a header), so we can avoid embedding an outline 
of the algorithm in this specification to get it done promptly?

The closest I could find is the "relaxed" Header Canonicalization Algorithm 
in RFC 4871 section 3.4.2.  But it has unnecessary steps and additional 
steps would be needed to remove the non-significant WSP from the addr-spec 
prior to comparison.  I don't think that's a good reference.

Can anyone think of a better reference?  I really don't want to be 
obstructionist about this, but I do think getting the algorithm specified 
will improve interoperability (since I've personally experienced S/MIME 
interoperability problems due to this issue).

As always, feel free to let me know if you feel my discuss position is not 
reasonable.  Getting the balance between quality and approval speed right 
is difficult and I do get it wrong sometimes, so feedback is welcome.

		Thanks,
		- Chris

_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Jan 2009 10:10:35 -0800

At 9:27 AM -0800 1/8/09, Chris Newman wrote:
>Can anyone think of a better reference?  I really don't want to be obstructionist about this, but I do think getting the algorithm specified will improve interoperability (since I've personally experienced S/MIME interoperability problems due to this issue).

It would be better if this algorithm came from the Apps community than expecting the security folks to come up with it.

>As always, feel free to let me know if you feel my discuss position is not reasonable.  Getting the balance between quality and approval speed right is difficult and I do get it wrong sometimes, so feedback is welcome.

Given that this same wording is in RFC 3850 and even its predecessor (RFC 2632), it seems a bit onerous to require this now. I agree that there could be a BCP on address matching, but stopping a bis (or, reall, ter) document on it seems over the top.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 08 Jan 2009 14:21:17 -0500

- I guess one has to take into account EAI too...
- therefore, a possible draft which takes into account EAI would be a
good doc.

Marc.

Chris Newman a écrit :
> comparison of email addresses but did not specify the algorithm for
> doing so.
> 
> email addresses (one from a header), so we can avoid embedding an
> outline of the algorithm in this specification to get it done promptly?
> 
> The closest I could find is the "relaxed" Header Canonicalization
> Algorithm in RFC 4871 section 3.4.2.  But it has unnecessary steps and
> additional steps would be needed to remove the non-significant WSP from
> the addr-spec prior to comparison.  I don't think that's a good reference.
> 
> obstructionist about this, but I do think getting the algorithm
> specified will improve interoperability (since I've personally
> experienced S/MIME interoperability problems due to this issue).
> 
> As always, feel free to let me know if you feel my discuss position is
> not reasonable.  Getting the balance between quality and approval speed
> right is difficult and I do get it wrong sometimes, so feedback is welcome.
> 
>         Thanks,
>         - Chris
> 

-- 
=========
IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca