Subject: [pkix] Strings in certificates

From: Peter Bowen <[email-masked]>
Date: Mon, 18 Jan 2016 19:10:02 -0800

In writing certlint (https://github.com/awslabs/certlint), I ran
across several items related to strings in certificates that are
slightly unclear.  I’m hoping that someone might be able to help
clarify a few things:

1) TeletexString, BMPString, and UniversalString types of DirectoryStrings

RFC 5280 says CAs should not use TeletexString, BMPString, and
UniversalString types for DirectoryStrings.  As early as 1999 (RFC
2459) these were flagged as deprecated.

Is there anything that has moved these to SHALL NOT/MUST NOT or are we
still at SHOULD NOT?

2) VisibleString and BMPString types of DisplayText

RFC 5280 says:
      Conforming CAs SHOULD use the
      UTF8String encoding for explicitText, but MAY use IA5String.
      Conforming CAs MUST NOT encode explicitText as VisibleString or
      BMPString.

However the organization field of noticeref also uses DisplayText.  Do
the same rules apply?

3) Unicode normalization

A number of fields in certificates can take unicode strings.  Is there
any specification as to how (or if) they should be normalized?

4) Control characters

Is there ever a valid use case for including control characters (e.g.,
U+0000 to U+001F and U+007F to U+009F) in a string?

Thanks,
Peter

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 19 Jan 2016 09:33:07 +0100

Bonjour Peter,

> slightly unclear.  I’m hoping that someone might be able to help

[...]

> U+0000 to U+001F and U+007F to U+009F) in a string?

This is described in X.520, in section 3 (matching rules and syntaxes), and
more specifically at clause 7. But that's only for strings comparison
(between certificates), not string storage inside certificates.

-- 
Erwann.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 19 Jan 2016 10:54:08 +0000

On 19/01/16 08:33, Erwann Abalea wrote:
> Bonjour Peter,
>
> 2016-01-19 4:10 GMT+01:00 Peter Bowen <[email-masked]
> <mailto:[email-masked]>>:
>
> This is described in X.520, in section 3 (matching rules and syntaxes),
> and more specifically at clause 7. But that's only for strings
> comparison (between certificates), not string storage inside certificates.

X.690 defines DER (and BER and CER).  I'm looking at the December 1997 
edition, which says:

"8.20.10 For the "UTF8String" type, the octet string shall contain the 
octets specified in ISO/IEC 10646-1/Amd.2.  Announcers and escape 
sequences shall not be used, and each character shall be encoded in the 
smallest number of octets available for that character."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 19 Jan 2016 14:34:01 +0100

2016-01-19 11:54 GMT+01:00 Rob Stradling <[email-masked]>:

> octets specified in ISO/IEC 10646-1/Amd.2.  Announcers and escape sequences
> shall not be used, and each character shall be encoded in the smallest
> number of octets available for that character."

You're right, Rob. In the 2015 edition, the section has moved to 8.23.10,
and "ISO/IEC 10646-1/Amd.2" is now "ISO/IEC 10646, Annex D". And it's not
even limited to DER.

-- 
Erwann.

---

From: Sean Turner <[email-masked]>
Date: Mon, 25 Jan 2016 17:25:30 -0500

My two cents …

> Is there anything that has moved these to SHALL NOT/MUST NOT or are we

I’d love to hear that CAs haven’t generated these string types for the last decade ….

> However the organization field of noticeref also uses DisplayText.  Do

I remember something about this … ah yeah @ IETF 74:
https://ietf.org/proceedings/74/slides/pkix-3.pdf

I think it was just meant to apply to explicitText because that’s what was seen in the wild given the following statement in s4.2.1.4:
"Conforming CAs SHOULD NOT use the noticeRef option.”

> any specification as to how (or if) they should be normalized?

I thought there were references in s7 of RFC 5280 (and some tweaks in s5 of RFC 6818).  There’s also some additional information in RFC 6125.  In a perfect world, the output of precis (https://datatracker.ietf.org/wg/precis/documents/) would be adopted the world over.  I’m not going to hold my breath though.

spt

---

From: Peter Bowen <[email-masked]>
Date: Mon, 25 Jan 2016 17:46:26 -0800

Sean,

Thanks for providing your thoughts.

> I’d love to hear that CAs haven’t generated these string types for the last decade ….

You won't hear that from me.  I've seen hundreds (if not thousands) of
certificates issued in the last week that use these string types.

> "Conforming CAs SHOULD NOT use the noticeRef option.”

Yes, I was pointed to RFC 6818 which changed this rule.

> I thought there were references in s7 of RFC 5280 (and some tweaks in s5 of RFC 6818).  There’s also some additional information in RFC 6125.  In a perfect world, the output of precis (https://data…

I don't see anything there that specifies a specific normalization
form for storage, except for the one thing about explicitText.  I'll
assuming anything (including mixed) is good.

Thanks,
Peter