[Top posting because previous post did]
As a relying party and a subscriber of some certificates, I would
consider each of the following combinations as something that should be
both permitted and useful under any future rules, even if the current
BRs don't allow it.
1. O=Actual Org name and
Yes. I'm concerned about an interpretation that says the Subject field
doesn't identify the Subject, while also being sensitive to past
discussions (e.g. dnQualifier) that are explicitly specified not to
identify the Subject. The OU, as specified both in the BRs and within the
relevant ITU-T
All,
The updated proposed section is here:
https://github.com/mozilla/www.ccadb.org/issues/33#issuecomment-548884075
Please let me know if you have any further feedback on this proposed
addition to the Common CCADB Policy.
Thanks,
Kathleen
___
My view is that the OU field is a subject distinguished name field and that a
CA must have a process to prevent unverified information from being included in
the field.
Subject Identity Information is defined as information that identifies the
Certificate Subject.
I suppose the answer to your
> -Original Message-
> From: Kurt Roeckx via dev-security-policy
> Sent: 01 November 2019 10:15
> To: Matthias van de Meent
> Cc: MDSP
> Subject: Re: Certificate OU= fields with missing O= field
>
> On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via dev-
>
Is your view that the OU is not Subject Identity Information, despite that
being the Identity Information that appears in the Subject? Are there other
fields and values that you believe are not SII? This seems inconsistent
with 7.1.4.2, the section in which this is placed.
As to the .com in the
A mistake in the BRs (I wrote the language unfortunately so shame on me for not
matching the other sections of org name or the given name). There's no
certificate that ever contains all of these fields. How would you ever have
that?
There's no requirement that the OU field information relate
On Fri, Nov 1, 2019 at 5:14 AM Kurt Roeckx via dev-security-policy
wrote:
>
> On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via
> dev-security-policy wrote:
> > Hi,
> >
> > I recently noticed that a lot of leaf certificates [0] have
> > organizationalUnitName specified without
Hi,
I was notified that the attachments were lost in transmission, so here
are the links:
cert_no_dcv: https://drive.google.com/open?id=1s43AaW5lCkSzbr-If6l2F_gwLkwDVy6w
cert_by_issuer_no_dcv:
https://drive.google.com/open?id=1-er8R2CfcG8CRK4I3KUXnv8PDgGQKc1Y
cert_by_issuer_name_no_dcv:
On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via
dev-security-policy wrote:
> Hi,
>
> I recently noticed that a lot of leaf certificates [0] have
> organizationalUnitName specified without other organizational
> information such as organizationName. Many times this field is
Hi,
I recently noticed that a lot of leaf certificates [0] have
organizationalUnitName specified without other organizational
information such as organizationName. Many times this field is used
for branding purposes, e.g. "issued through "
or "SomeBrand SSL".
BR v1.6.6 ยง 7.1.4.2.2i has guidance
11 matches
Mail list logo
