Subject: [EAI] SMIME certificate and utf8header normalization

From: Soobok Lee <[email-masked]>
Date: Thu, 14 Dec 2006 01:28:38 +0900

As Charles expressed concerns about "no requirement for header normalization",
that prompts me to raise the following SMIME related issue:

<issue>
 SMIME signature/encryption use sender/recipient's certificates respectively.

 Email certificate contains Issuer and Subject field.
 Subject field's DN contains the email address which
  should be the same with From: or TO: address in the message header.

  If MUA's email address is _not_ in NFC/NFKC,
   SMIME signature/encryption may fail in some cases, due to failure
   to find the matching email certificate which may be in NFC or in NFKC.
   The signature verification will succeed always because it is already
    successfully signed (find the matched certificate successfully).

  Subject's DN should be unique under the Issuer CA, so the DN's
   email address also should be unique. 
   To be unique, the EAI email address had better be created 
    in a normalized form.

  Then, From/To/Cc email addresses should have the same normalization form
    as future SMIME certificate's normalization.
</issue>

Is this issue is valid ? or already discussed ?
Is this issue out of protocol issue and better be put in advice draft ?

I read x.509 certificate standard RFC2459 ( http://www.ietf.org/rfc/rfc2459.txt), 
   and DN standard RFC2247 ( http://www.ietf.org/rfc/rfc2247.txt), 
but I can't find any normalization-related stuff in these RFCes.

I have little knowledge about commercial CA's policy on normalization of 
NON-ASCII DN/email address. They may have no policy yet on EAI email address
which is in still in embryo stage.

Soobok 

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Soobok Lee <[email-masked]>
Date: Thu, 14 Dec 2006 10:29:16 +0900

FYI,
I followed also RFC2459 -> RFC3280 -> RFC4630 path and 
 RFC2279 for UTF8String cited by RFC4630 & RFC3280.
But, I can't find any normalization stuff in these drafts.

And  RFC3280 says:
======
 Housley, et. al.            Standards Track                    [Page 33]
RFC 3280        Internet X.509 Public Key Infrastructure      April 2002

   subjectAltName extension MUST be present.  If the subject field
   contains an empty sequence, the subjectAltName extension MUST be
   marked critical.

   When the subjectAltName extension contains an Internet mail address,
   the address MUST be included as an rfc822Name.  The format of an
   rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822].  An
   addr-spec has the form "local-part@domain".  Note that an addr-spec
   has no phrase (such as a common name) before it, has no comment (text
   surrounded in parentheses) after it, and is not surrounded by "<" and
   ">".  Note that while upper and lower case letters are allowed in an
   RFC 822 addr-spec, no significance is attached to the case.

   When the subjectAltName extension contains a iPAddress, the address
   MUST be stored in the octet string in "network byte order," as
   specified in RFC 791 [RFC 791].  The least significant bit (LSB) of
   each octet is the LSB of the corresponding byte in the network
   address.  For IP Version 4, as specified in RFC 791, the octet string
   MUST contain exactly four octets.  For IP Version 6, as specified in
   RFC 1883, the octet string MUST contain exactly sixteen octets [RFC
   1883].

   When the subjectAltName extension contains a domain name system
   label, the domain name MUST be stored in the dNSName (an IA5String).
   The name MUST be in the "preferred name syntax," as specified by RFC
   1034 [RFC 1034].  Note that while upper and lower case letters are
   allowed in domain names, no signifigance is attached to the case.  In
   addition, while the string " " is a legal domain name, subjectAltName
   extensions with a dNSName of " " MUST NOT be used.  Finally, the use
   of the DNS representation for Internet mail addresses (wpolk.nist.gov
   instead of [email-masked]) MUST NOT be used; such identities are to
   be encoded as rfc822Name.

   Note: work is currently underway to specify domain names in
   international character sets.  Such names will likely not be
   accommodated by IA5String.  Once this work is complete, this profile
   will be revisited and the appropriate functionality will be added.
====== 
This means we should have punycode-encoded hostname part for EAI email 
address for certificate subject DN or subjectAltName 
unless these paragraph are revised ??   

Soobok

-----
Conclusion: If RFC3280 is the most recent one, 
we should encode [email-masked] as NON-ASCII@xn--****.com.

---

From: Soobok Lee <[email-masked]>
Date: Thu, 14 Dec 2006 12:12:31 +0900

If my finding is correct (i am not sure of it yet),
these paragraphs may be added to some drafts:

<suggest>
 current x.509 PKI certficate profile (RFC4630,RFC3280) does not 
  allow full UTF8-encoded email addresses 
  in Subject DN and subjectAltName.
 Further standardization is required in X.509 PKI profile and SMIME.

 Future x.509 certificate profile is expected to state:
   o EmailAddress attribute value should be
        encoded in UTF8String for both local-part and hostname part and
        and no normalization and casefolding is required for them.
   o EmailAddress attribute value should be treated by applications
        in normalization-insensitive and case-insensitive way.
</suggest>

So, utf8header now don't need any requirement for normalization 
  especially for future SMIME  and x.509 PKI certificate profile,
  if EAI email address is treated in normalization-insensitive way.

By "normalization-insensitive & case-insensitive", I mean
  A === B if lowercase(NFKC(A))==lowercase(NFKC(B)) OR 
	     lowercase(NFKD(A))==lowercase(NFKD(B)).
   (NFC is included in NFKC).

My finding is not yet complete. I welcome any correction.

Soobok

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 Dec 2006 12:01:08 +0100

> My finding is not yet complete. I welcome any correction.
Again: S/MIME is not on our current agenda. It is on the list of issues 
we have to tackle once we have the basic protocol proposals done.

                  Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 14 Dec 2006 12:24:42 -0000

>   should be the same with From: or TO: address in the message header.

Yes, this is just another example, on top of mailtos and Vcards that I  
have already mentioned, where mail addresses may appear and be publicised.  
And maybe at a later stage we have to produce documents about them.

But what these all have in common is that they are usually generated by  
the owners of the domains (or their postmasters, or their users), and are  
therefore under their control, So if the domain has established some  
policy regarding normalization of their <localpart>s (as I think they  
SHOULD), then any certificates, mailtos, Vcards, etc that they generate  
will naturally be in that normalized form. In which case everything will  
work fine and there is no need for us to worry about it at this stage.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5