I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the Baseline Requirements. It's also deprecated.
On Thu, Jan 24, 2019 at 8:17 AM Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I agree with Rufus. There are really two issues here:
>
> 1) The original reports to the CAs claimed an issue because RFC 5280
> references the original IDNA RFCs (now known as
Good morning!
I would like to sharpen my argument from below a little bit: If a CA gets a
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can
the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not only a
very strange server name? At least I don't have
On 2019-01-24 9:47, Buschart, Rufus wrote:
Good morning!
I would like to sharpen my argument from below a little bit: If a CA gets a
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can
the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not only a
Hello Dimitris,
of course not, because the underscore is not part of the syntax for a hostname
acc. RFC 1034, chapter 3.5. whereas xn--gau-7ka.siemens.de is a perfectly valid
hostname.
With best regards,
Rufus Buschart
Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT
On Thu, 24 Jan 2019 11:14:11 +
"Buschart, Rufus via dev-security-policy"
wrote:
> You are right, of course there are mandatory RFC to take into
> account. But there is - to my knowledge - no RFC that says, you MUST
> NOT issue a certificate to a domain that could be interpreted as an
>
Hello Kurt!
We don't fill in the CN of a certificate. We verify that in the CSR of the
customer the subject:CommonName is part of the extensions:subjectAltName (as
required in BRGs 7.1.4.2.2.a). So we would only issue a certificate with:
{
CN = xn--gau-7ka.siemens.de
SAN =
On 24/1/2019 10:47 π.μ., Buschart, Rufus via dev-security-policy wrote:
Good morning!
I would like to sharpen my argument from below a little bit: If a CA gets a
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can
the CA tell, that xn--gau-7ka is a punycode string in
Hello Dimitris!
You are right, of course there are mandatory RFC to take into account. But
there is - to my knowledge - no RFC that says, you MUST NOT issue a certificate
to a domain that could be interpreted as an IDNA2008 punycode.
With best regards,
Rufus Buschart
Siemens AG
Information
Hello
> -Ursprüngliche Nachricht-
> Von: Hanno Böck
> Gesendet: Donnerstag, 24. Januar 2019 12:36
>
> On Thu, 24 Jan 2019 11:14:11 +
> "Buschart, Rufus via dev-security-policy"
> wrote:
>
> > You are right, of course there are mandatory RFC to take into account.
> > But there is -
I referred to your comment that "you perform a successful domain
validation". My point, which you seem to understand and agree, is that
there are additional rules than just DNS validation.
Dimitris.
On 24/1/2019 12:21 μ.μ., Buschart, Rufus wrote:
Hello Dimitris,
of course not, because the
On 24/01/2019 09:04, Kurt Roeckx via dev-security-policy wrote:
> On 2019-01-24 9:47, Buschart, Rufus wrote:
>> Good morning!
>>
>> I would like to sharpen my argument from below a little bit: If a CA
>> gets a request to issue a certificate for the domain
>> xn--gau-7ka.siemens.de, how can the
On 2019-01-24 12:08, Rob Stradling wrote:
Hi Kurt.
BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
address or Fully-Qualified Domain Name that is one of the values
contained in the Certificate’s subjectAltName extension (see Section
7.1.4.2.1)."
Fitting the U-label
On 24/01/2019 14:09, Kurt Roeckx via dev-security-policy wrote:
> On 2019-01-24 12:08, Rob Stradling wrote:
>>
>> Hi Kurt.
>>
>> BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
>> address or Fully-Qualified Domain Name that is one of the values
>> contained in the
On Thu, Jan 24, 2019 at 4:17 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hello
>
> > -Ursprüngliche Nachricht-
> > Von: Hanno Böck
> > Gesendet: Donnerstag, 24. Januar 2019 12:36
> >
> > On Thu, 24 Jan 2019 11:14:11 + Buschart, Rufus
On 2019-01-24 15:41, Rob Stradling wrote:
Here's an example cert containing the A-label in the SAN:dNSName and the
U-label in the CN. (It was issued by Sectigo, known back then as Comodo
CA, before we switched to always putting the A-label in the CN):
On Thu, Jan 24, 2019 at 7:36 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2019-01-24 15:41, Rob Stradling wrote:
> >
> > Here's an example cert containing the A-label in the SAN:dNSName and the
> > U-label in the CN. (It was issued by Sectigo, known
Hi Kurt!
> -Ursprüngliche Nachricht-
> Von: dev-security-policy Im
> Auftrag von Kurt Roeckx via dev-security-policy
> I expect all fields in the subject to be things you can just read, so
> U-labels. It does not make sense to show users an A-label, they do
> not understand what that
18 matches
Mail list logo
