certificates further
restrict the certificate contents.
Also, if it knows that the chances of anything being able to correctly handle
a particular string form is essentially zero, even if some interpretation of
the spec can claim it's OK, shouldn't it warn?
Therefore, any use of permitted ISO 2022 esc
Kurt Roeckx writes:
>As I understand it, it was the Swedish government, and they claimed that
>Microsoft said it was ok. They just contained latin1.
That sounds right then, latin-1 would cover Sweden, and given the T61String =
latin1 that most (all?) implementations apply it should work fine.
Kurt Roeckx writes:
>I have yet to see a certificate that doesn't just put latin1 in it, which
>should get rejected.
There were some Deutsche Telekom certificates from the late 1990s that used
T61String floating diacritics for which I had some custom code to identify the
two-character sequences
​Ryan Sleevi writes:
>Is that because you believe it forbidden by spec, or simply unwise?
The spec allows almost anything, and in particular because there isn't any one
definitive "spec" you can have ten incompatible interpretations that are all
compliant to something that can claim to be the
are just broken. I have yet to see a certificate
> that doesn't just put latin1 in it, which should get rejected.
>
> Anyway, at some point I started writing a proper parser for
> teletexstring. But I don't think it's worth my time if there are 0
> valid certificates using it. If so
latin1 in it, which should get rejected.
rfc2459, from 1999, already said TeletexString is only for
backward compatability and you MUST switch to UTF8String by
2004, but you can keep using it forever if you established
an identity before that. Because clearly if you change the
encoding people will not rec
On Sat, Jul 7, 2018 at 4:43 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via
> dev-security-policy wrote:
> >
> > So for certlint I'd always warn for T61String with anything other than
> ASCII
> >
Kurt Roeckx writes:
>I think it should generate an error on any character not defined in 102 and
>the space character. So any time you try to use anything in C0, C1 and G1,
>and those 6 in 102 that are not defined.
Yep, sounds good. With a possible check for latin-1 validity as well in case
On Sat, Jul 07, 2018 at 10:43:26AM +0200, Kurt Roeckx via dev-security-policy
wrote:
> On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via
> dev-security-policy wrote:
> >
> > So for certlint I'd always warn for T61String with anything other than ASCII
> > (which century are they living
hat is
> > allowed in a certificate in data encoded as "TeletexString" (which is
> > also sometimes called T61String).
> >
> > Specifically, certlint will report an error if a TeletexString
> > contains any characters not in the "Teletex Primary Set of Grap
On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via dev-security-policy
wrote:
>
> So for certlint I'd always warn for T61String with anything other than ASCII
> (which century are they living in? Point them at UTF8 and tell them to come
> back when they've implemented it), treat it as a
On Fri, Jul 06, 2018 at 02:43:45PM -0700, Peter Bowen via dev-security-policy
wrote:
> In reviewing a recent CA application, the question came up of what is
> allowed in a certificate in data encoded as "TeletexString" (which is
> also sometimes called T61String).
>
&g
Peter Bowen via dev-security-policy
writes:
>In reviewing a recent CA application, the question came up of what is allowed
>in a certificate in data encoded as "TeletexString" (which is also sometimes
>called T61String).
For the full story of T.61 strings, see the X.509
In reviewing a recent CA application, the question came up of what is
allowed in a certificate in data encoded as "TeletexString" (which is
also sometimes called T61String).
Specifically, certlint will report an error if a TeletexString
contains any characters not in the "Tele
14 matches
Mail list logo
