Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)
draft-ietf-smime-bfibecms-10

[Ballot discuss]
[picking up Sam's discuss]

>      The RFC822email is the e-mail address of the recipient in
>      the format defined by [TEXTMSG]. E-mail addresses that
>        contain non-ASCII characters MUST be encoded using punycode
>      [PUNYCODE].

Is this consistent with how we're handling email internationalization
for local parts?

[Ballot comment]
John Klensin noticed this while reviewing the document and my
discuss text:

The references in this document are a mess.  The two I
spotted immediately are that, while Brandner is a significant
figure around the ITU community, he is not the author of RFC
2119 and Dave Crocker is not the author of 2822, nor does 2822
have the same title as 2821.  I'm on an airplane and can't
check, but I suspect that [DER] is similarly botched, with a
mismatch between author, title, and date (and it is
insufficiently specific for the pointer from the text).

[Ballot discuss]
Updated 2007-12-07:

I had a discussion with Russ and it's my understanding the WG wants to
be future compatible with EAI and the requirement is that the syntax
in this field has to effectively work for a memcmp() based comparison.
Those are laudable goals so we've done our best to come up with a
concrete proposal for the document.  Here's an outline:

To support EAI email addresses, the field does have to be a
UTF8String.  We now understand that Punycode on the local-part doesn't
work due to the issue below.

For memcmp comparison, the domain part has to be converted from
display form to DNS protocol form, so that means the right hand side
of the email address has to be IDNA encoded (RFC 3940, normative
reference). Be aware there is a revision of RFC 3940 in progress that
will change it so it doesn't depend on a specific Unicode version.

For the email local part, EAI uses bare UTF-8 (STD#63) as a protocol
element without encoding.  However, as an informative reference point
to draft-klensin-net-utf8 as advice for enrollment and user interfaces
to deal with the Unicode issues.  Also mention that only US-ASCII
local parts can be used with un-extended SMTP (RFC 2821) but that
the UTF-8 support in the local part exists for future compatibility
with internationalized email (RFC 4952, also an informative reference).

Section 2.3.10 of RFC 2821 specifies the architectural restriction on
the email local part: "the local-part MUST be interpreted and
assigned semantics only by the host specified in the domain part of
the address."  As a result, we can't recommend any transformations on
the local-part that alter its semantics in any way.  It may be helpful
to refer to or repeat that architectural principle to explain the
approach.

Practice has shown that deployments simply avoid use of problematic characters.  For example, RFC 2821/2822 permits control characters in
email addresses but deployments just don't do that and it's therefore
simply not an interop issue in practice.  There are certainly more
problematic characters in UTF-8 but I expect a similar behavior
pattern in practice.  Unicode gets us close enough to fuzzy human
factors that the set of problematic characters will have regional
variations so attempting to over-constrain it in a specification can
lead to problems.

Note that a choice to use 7-bit only IA5String for the email address
(with IDN but without EAI support) is also acceptable as a path forward.
Given EAI is not yet approved and is slated to be experimental
initially, the IESG/apps area finds new protocols without EAI support
completely acceptable.

Let me know if you need further clarification.

---
Previous discuss text:

The email address used for identity should be a minimal-form RFC 2821
address with the domain name folded to lower case, not an RFC 2822
address.  RFC 2822 allows arbitrary comments and folding whitespace in
the address.  Both forms allow quoting and mixed-case domain names.

A discussion of whether ACE-encoded or UTF-8 encoded domain names are
used in the canonical format is needed (refer to IDN).  Note that RFC
2821 local parts are not permitted to contain 8-bit, although a future
extension to allow use of UTF-8 in local parts may occur.  Processors
should either fail if the local part contains any 8-bit, or fail if the
local part contains 8-bit that does not meet the syntax of UTF-8.

If compatibility with EAI (RFC 4952) is desired, then the syntax has
to support native UTF-8 text.  Specifically, the EAI architecture
does not allow use of punycode on the left-hand-side of an email
address and discourages use of punycode on the right-hand-side if
the left-hand-side allows non-ASCII characters.  See RFC 4952 section
4.1 sub-item 1.  If compatibility with EAI is not desired, then
punycode has to be limited to the domain-portion (right-hand-side).

Note that punycode alters the data in ways that is highly inappropriate
for the left-hand-side of an email address.  In particularly, the syntax
of the left-hand-side is owned 100% by the domain on the right hand side
so placing any syntax restrictions by virtue of an encoding violates a
fundamental principle of email addresses.

The "GeneralizedTime" ASN.1 syntax element permits "local time",
a time without any zone referent so it doesn't interoperate.  It should
be mandatory to either include a UTC offset or use UTC.  See RFC 3339
section 4.4 for further discussion.

[Ballot discuss]
The email address used for identity should be a minimal-form RFC 2821
address with the domain name folded to lower case, not an RFC 2822
address.  RFC 2822 allows arbitrary comments and folding whitespace in
the address.  Both forms allow quoting and mixed-case domain names.

A discussion of whether ACE-encoded or UTF-8 encoded domain names are
used in the canonical format is needed (refer to IDN).  Note that RFC
2821 local parts are not permitted to contain 8-bit, although a future
extension to allow use of UTF-8 in local parts may occur.  Processors
should either fail if the local part contains any 8-bit, or fail if the
local part contains 8-bit that does not meet the syntax of UTF-8.

If compatibility with EAI (RFC 4952) is desired, then the syntax has
to support native UTF-8 text.  Specifically, the EAI architecture
does not allow use of punycode on the left-hand-side of an email
address and discourages use of punycode on the right-hand-side if
the left-hand-side allows non-ASCII characters.  See RFC 4952 section
4.1 sub-item 1.  If compatibility with EAI is not desired, then
punycode has to be limited to the domain-portion (right-hand-side).

Note that punycode alters the data in ways that is highly inappropriate
for the left-hand-side of an email address.  In particularly, the syntax
of the left-hand-side is owned 100% by the domain on the right hand side
so placing any syntax restrictions by virtue of an encoding violates a
fundamental principle of email addresses.

(Note my previous comment about IA5String was incorrect, use of
IA5String is acceptable if EAI compatibility is not desired.  As EAI
is not standards track, it is not appropriate for the IESG to mandate
EAI compatibility).

The "GeneralizedTime" ASN.1 syntax element permits "local time",
a time without any zone referent so it doesn't interoperate.  It should
be mandatory to either include a UTC offset or use UTC.  See RFC 3339
section 4.4 for further discussion.

[Ballot discuss]
The email address used for identity should be a minimal-form RFC 2821
address with the domain name folded to lower case, not an RFC 2822
address.  RFC 2822 allows arbitrary comments and folding whitespace in
the address.  Both forms allow quoting and mixed-case domain names.

A discussion of whether ACE-encoded or UTF-8 encoded domain names are
used in the canonical format is needed (refer to IDN).  Note that RFC
2821 local parts are not permitted to contain 8-bit, although a future
extension to allow use of UTF-8 in local parts may occur.  Processors
should either fail if the local part contains any 8-bit, or fail if the
local part contains 8-bit that does not meet the syntax of UTF-8.

The use of IA5String syntax for an email address is highly inappropriate
as it would require processors to perform charset conversions from ISO
2022 and other highly complex charsets (introducing a great deal of
security and interoperability risk).  A syntax that only permits UTF-8
would be preferred.

The "GeneralizedTime" ASN.1 syntax element permits "local time",
a time without any zone referent so it doesn't interoperate.  It should
be mandatory to either include a UTC offset or use UTC.  See RFC 3339
section 4.4 for further discussion.

ASN.1 has serious security considerations that have resulted
in many real-world vulnerabilities in security software.  Specifically,
the nested lengths in ASN.1 can be inconsistent so ASN.1 parsers must
be prepared for such inconsistencies that might result in buffer
overflows or lengths that would cause a DOS if allocated.  This document
fails to discuss or reference ASN.1 security considerations.

[Ballot discuss]
>      The RFC822email is the e-mail address of the recipient in
>      the format defined by [TEXTMSG]. E-mail addresses that
>        contain non-ASCII characters MUST be encoded using punycode
>      [PUNYCODE].

Is this consistent with how we're handling email internationalization
for local parts?

draft-ietf-smime-bfibecms-07 is ready for IETF-wide last call. Below find the                                                                                                                 
Document Shepherd writeup.

Answering questions 1.a-1.h in RFC 4858:

1.a - Blake Ramsdell is the Shepherd.  He's personally reviewed the document
      and knows it is ready for IESG publication.

1.b - The document has been reviewed by key WG members.

1.c - There is no need for wider review.

1.d - There are no specific concerns that the AD and/or IESG should be aware
      of.

1.e - The WG was relatively quiet about this document.

1.f - There has been no threat of an appeal.

1.g - The nits have been addressed.

1.h - The document splits it references.

1.i - The document has an IANA consideration and it is consistent with the
      main body (there are no IANA considerations).

1.j - The reviewer has NOT personally verified the ASN.1, but knows at least
      two others that have.

1.h - Write-up is as follows:

Technical Summary

This document describes the conventions for using the Boneh-Franklin (BF) and
Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic
Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers
and the convention for encoding a recipient's identity are also defined.

Working Group Summary

There was very little public discussion about this draft. During WG last call
comments were raised and addressed, and after last call some nits were
addressed.

Document Quality

I know that there is at least one implementation by Voltage of this protocol.
I am not aware of other vendor plans for implementation.

Personnel

Blake Ramsdell  is the document Shepherd. Tim Polk
is the responsible Security Area AD.

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com