Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-03.txt

From: [email-masked]
Date: Thu, 11 Aug 2011 07:53:30 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Clarifications to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
	Author(s)       : David Cooper
	Filename        : draft-ietf-pkix-rfc5280-clarifications-03.txt
	Pages           : 5
	Date            : 2011-08-11

   This document updates RFC 5280, the Internet X.509 Public Key
   Infrastructure Certificate and Certificate Revocation List (CRL)
   Profile.  This document changes the set of acceptable encoding
   methods for the explicitText field of the user notice policy
   qualifier and clarifies the rules for converting internationalized
   domain name labels to ASCII.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc5280-clarifications-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc5280-clarifications-03.txt

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Aug 2011 17:37:20 +0200 (MEST)

>    domain name labels to ASCII.

With respect to section 2 
2.  Update to RFC 5280, Section 4.2.1.4: Certificate Policies

I don't like this:

      The explicitText string SHOULD NOT include any control
      characters (e.g., U+0000 to U+001F and U+007F to U+009F).

and would strongly prefer if it said

      Implementations SHOULD reject certificates that include the
      control character U+0000 in the explicitText string, and
      implementations MAY reject certificates that include control
      characters from the range U+0001 to U+001F) in the explicitText
      string independent of the attribute encoding that is used.

If you believe that any control characters from the range
U+0000 to U+001f should be tolerated, please provide a convincing
rationale for each character individually.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Aug 2011 17:41:43 +0200 (MEST)

Sorry, I goofed the recipients on my reply.
(Please be careful before replying to my last Email)

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Aug 2011 12:16:33 -0400

> rationale for each character individually.

We want CAs to refuse to issue certificates with these characters.

I do not think we should require relying parties to scan the text field for the presence of these control characters as a step in certificate validation.

Russ

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Aug 2011 18:50:18 +0200 (MEST)

Russ Housley wrote:
> I do not think we should require relying parties to scan the text
> field for the presence of these control characters as a step in
> certificate validation.

I did _not_ write a "required" = MUST / SHALL.
This was a SHOULD reject for U+0000 and a MAY reject for U+0001-U+001f.

For some encodings (e.g. VisibleString) this restriction ought to be
a side effect automatically enforced by a sensible ASN.1 decoder.

But I would appreciate some pressure on CAs to discontinue doing
such nonsense and face interop problems in the long run if they
ignore it.   U+0000 is well-known to cause all sorts of problems
for textual information.  U+0000 caused real security problems
when used in cert subject DNames in TLS clients doing server 
endpoint identification according to rfc2818.

-Martin

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Aug 2011 12:54:26 -0400

> endpoint identification according to rfc2818.

My point is that you are shifting the actor from the AC to the relying party.

Russ

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Aug 2011 19:02:11 +0200 (MEST)

> My point is that you are shifting the actor from the AC to the relying party.

No, quite the contrary.

The current proposal does _not_ allow the relying party to reject such
a cert, which is really bad.  If it was changed to "an implementation
MAY reject", then the responsibility&blame for failures would be
completely transferred to the CA instead.

-Martin