> -----Original Message----- > From: dane [mailto:[email protected]] On Behalf Of Lyndon Nerenberg > Sent: Sunday, April 05, 2015 6:57 PM > To: Paul Hoffman > Cc: [email protected] > Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and > then for draft-ietf-dane-smime) > > > On Apr 5, 2015, at 6:22 PM, Paul Hoffman <[email protected]> wrote: > > > Greetings again. The discussion about exact-match and discovery in draft- > ietf-dane-openpgpkey has been useful for finding out what the use cases are, > and it's time to settle on a design that works for most people (we're never > going to make everyone happy). > > How can we possibly do that without real experience in the field? > > I know for a fact the case insensitive hashing rules will break Cyrus, where > foo+Bar@mumble will deliver to mailbox 'inbox.Bar', which is distinct from > foo+bar@mumble, delivering to 'inbox.bar'. Folder names are case sensitive, > so the two addresses are not equivalencies.
What I read of Paul's message was that the hashing would be on case sensitive strings. This means that the two strings above will produce different results. > > Ultimately, I don't see a way out of this other than to make a standard for sub- > addressing, with a well defined cut-point delimiter. If this is going to be done, then it will need to be back ported into the S/MIME and PGP specifications as well. The S/MIME specification says that names SHOULD be matched case insensitive, I was unable to find any rules in the OpenPGP spec for how user IDs and email address are matched. However, neither of these documents dealt with sub-addressing in any way and would ignore the fact that one is trying to do this. Thus foo+Bar and foo+bar are going to be matched, but [email protected] and [email protected] are not going to be matched by S/MIME implementations. In S/MIME this decision was made to make most people happy. However, I do know that there are implementations where the names are matched case sensitive rather than case insensitive. Jim > > But that still doesn't change how the LHS has been defined as case-sensitive > since the dawn of time. If we are to change this, RFC5322 3.4.1 needs a > change in its last paragraph. As things stand, we cannot treat <local-part> as > case-insensitive in any interpretation of the grammar. > > --lyndon _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
