Subject: Re: [pkix] Strings in certificates

From: Wei Chuang <[email-masked]>
Date: Fri, 5 Feb 2016 15:10:00 -0800

On Mon, Jan 25, 2016 at 5:46 PM, Peter Bowen <[email-masked]> wrote:

> Sean,
>
> Thanks for providing your thoughts.
>
> On Mon, Jan 25, 2016 at 2:25 PM, Sean Turner <[email-masked]> wrote:
> > My two cents …
> >
> > On Jan 18, 2016, at 22:10, Peter Bowen <[email-masked]> wrote:
> >>
> >> 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?
> >
> > 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.
>
> >> 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?
> >
> > 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.”
>
> Yes, I was pointed to RFC 6818 which changed this rule.
>
> >> 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?
> >
> > 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.
>
> 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.
>

Just piling on.  May be I'm misreading those two section (s7 of RFC5280 and
s5 of RFC6818), while there's IDN support, there's no mention of handling
Unicode in email address rfc822Name local-part or URL uniformResourceIdentifier
path or query parts.  It seems like an important loophole that should be
fixed.  Would folks here be willing to help in standardizing some in
certificate encoding for these types?

thanks,
-Wei

>
> Thanks,
> Peter
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 5 Feb 2016 18:40:54 -0500

On Feb 5, 2016, at 6:10 PM, Wei Chuang wrote:

> > 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.
> 
> Just piling on.  May be I'm misreading those two section (s7 of RFC5280 and s5 of RFC6818), while there's IDN support, there's no mention of handling Unicode in email address rfc822Name local-part or URL uniformResourceIdentifier path or query parts.  It seems like an important loophole that should be fixed.  Would folks here be willing to help in standardizing some in certificate encoding for these types?

I'm willing to help with a clarifications document.  I do not need to revisit the decisions recorded in every section of RFC 5280 all over again.

Russ

---

From: Wei Chuang <[email-masked]>
Date: Fri, 5 Feb 2016 23:25:16 -0800

On Fri, Feb 5, 2016 at 3:40 PM, Russ Housley <[email-masked]> wrote:

>> > 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/
> Just piling on.  May be I'm misreading those two section (s7 of RFC5280
> and s5 of RFC6818), while there's IDN support, there's no mention of
> handling Unicode in email address rfc822Name local-part or URL uniformResourceIdentifier
> I'm willing to help with a clarifications document.
>

That sounds like a good approach.

-Wei

> I do not need to revisit the decisions recorded in every section of RFC
> 5280 all over again.
>
> Russ
>
>
>
>