Subject: RE: Last Call summary for draft-ietf-pkix-cert-utf8

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 11 Apr 2006 19:06:57 -0700

Sam,

How about the following:

"Different character strings can appear to be the same string to human
relying parties.  In order to reduce this risk, CAs should define and
follow appropriate policies to reduce this risk by:

1. Selecting their own names that are not easy to spoof to human relying
parties; and
2. Asserting subject names that are not easy to spoof to human relying
parties."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sam Hartman
Sent: Tuesday, April 11, 2006 8:46 PM
To: [email-masked]
Cc: [email-masked]
Subject: Last Call summary for draft-ietf-pkix-cert-utf8

Denis Pinkas indicated that he had strong concerns about the document
because of spoofing attacks.  He believed that we should recommend
PrintableString where possible.

Jim Schaad believed that supporting internationalization is important
and that we should afford people the same anti-spoofing protection
regardless of their character set.  Santosh Chokhani, Stefan Santesson
and Kurt Zeilenga also disagreed with Denis.  Kurt believed that
spoofing i a problem even in the PrintableString case.
Kurt believed that security considerations text such as the following
should be added to the draft:

     Two different character strings can easily appear (in
     common and/or a particular font) to be the same string and
     hence CAs should have and follow appropriate policies to
     reduce as to who is the subject of any certificate they issue.

Denis supported Kurt's text although he argued that it should go in
the main body of the document not the security considerations section.
Denis also proposed that we recommend the use of PrintableString where
possible.  There was general disagreement with this recommendation.

A few people disagreed with the idea of adding security considerations
text.

There was also a discussion of the appropriateness of CAs choosing to
issue certificates to anyone who had a domain name registered or
whether they should filter the certificate requests.  This discussion
is largely out of scope and reached no consensus.

I conclude there is no rough consensus to change the document in
regard to these issues.  I conclude that this discussion does not
challenge the rough consensus to publish the document.

However I find that Kurt has raised a substantive issue that must be
addressed before publication.  Neither RFC 3280 nor this draft
discusses the security consideration of one name being confused for
another.  This concern must be mentioned as a residual risk even if
there is no consensus to make a specific recommendation for mitigating
this risk.  So I will need wording possibly similar to that suggested
by Kurt to document this security consideration.  I would propose
accepting Kurt's wording except that it doesn't seem to parse as valid
English for me.
--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Apr 2006 11:51:29 -0400

>>>>> "Santosh" == Santosh Chokhani <[email-masked]> writes:

    Santosh> Sam, How about the following:

    Santosh> "Different character strings can appear to be the same
    Santosh> string to human relying parties.  

I'd add a sentence explaining why this is bad.  Something like "If
these strings are used to identify the subject of a certificate then a
human may believe he is communicating with  one subject when in fact he is
communicating with another."

    Santosh> In order to reduce this
    Santosh> risk, CAs should define and follow appropriate policies
    Santosh> to reduce this risk by:

I'm not sure there is consensus in the PKIX WG to give recommendations
on mitigation at this time. I do believe that PKIX needs to speak to
mitigation for 3280bis--either to explain why there is nothing we can
recommend and clearly describe the options or to recommend something.
However I do not think a prolonged discussion for this document is
desirable.  So, all I'm requiring for this document is documentation
of the residual risk.

--Sam