Re: [pkix] Strings in certificates

[Wei Chuang <[e-mail]>]

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

> Sean,
>
> Thanks for providing your thoughts.
>
> On Mon, Jan 25, 2016 at 2:25 PM, Sean Turner <[e-mail]> wrote:
> > My two cents …
> >
> > On Jan 18, 2016, at 22:10, Peter Bowen <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>