Telia CA - problem in E validation

Incident report:

PROBLEM IN SUBJECT E (email) VALUE VALIDATION (deviation 5)
Telia got a preliminary CA audit report on 25th June 2018. One of its BR de=
viations was a statement that "Telia did not have controls to adequately ve=
rify the email address information (of SSL certificates)". Telia has always=
 verified E values only visually and Registration officer (or certificate i=
nspector in some cases) has to manually accept each value but only clearly =
incorrect values or syntactically incorrect values have been thus far rejec=
ted. Note! Subject E value has only informative meaning and often includes =
support email address related to the server and it can't be used for SMIME =
purposes.

Timeline of actions:
10-Jul-2018 Telia decided to completely stop inserting E values to OV certi=
ficates because of this deviation because Telia won't know how they could b=
e reasonably verified otherwise. Plan is to implement this removal in Septe=
mber 2018. But before that Telia would like to get community opinion how E =
values are verified by other CAs and how they are supposed to be verified w=
hen BR text is like this "All other optional attributes, when present withi=
n the subject field, MUST contain information that has been verified by the=
 CA." Before this discussion Telia plan is not to revoke previously enrolle=
d OV certificates with visually verified E values.

Summary and details of problematic certificates:
Lots of existing Telia OV certificates have E value because Openssl which i=
s one of the most common CSR generators automatically adds it to the CSR an=
d old Telia process has accepted the values unless they are incorrect in vi=
sual verification or syntactically incorrect. Actual count and list of prob=
lematic E values will be generated in August 2018.

Explanation about how and why the mistakes were made or bugs introduced, an=
d how they avoided detection until now:
Telia hasn't understand that E values should be verified using some other m=
ethod than using visual check. Before this year it hasn't been on audit com=
ments even though Telia E verification process has been same always.

Steps to fix:
1. listing of problematic certificates; Telia plan to do this in August 201=
8
2. community discussion how other CAs verify E and how they are supposed to=
 be verified; planned to happen starting in August 2018 based on this bug
3. possible revocation or revalidation if community states that existing E =
values cause a security problem; will be done after public discussion


0
pekka
8/3/2018 8:53:30 AM
mozilla.dev.security.policy 1337 articles. 2 followers. Post Follow

24 Replies
68 Views

Similar Articles

[PageSpeed] 38

I want to emphasize that each and every value of certificate Subject have a=
lways been verified. It's wrong to say that those values are unverified. It=
 is only a question about E verification method and quality. Our method has=
 been to estimate visually by Registration Officer if each E value (or othe=
r subject value outside common group C,O,ST,L, streetAddress, postalCode) i=
s correct for this Customer.  =20

Registration Officer training has instructed which E values must be rejecte=
d. It is not possible to use visually similar kinds of characters because w=
e technically restrict Subject characters to common ASCII characters (e.g. =
nulls are rejected). It is completely incorrect to claim that any values ar=
e added  without validation. Since Feb 2018 Telia also techically prevents =
any other values than C,O,L,OU,E,CN from inserted to SSL certificates. Sinc=
e that the simple visual verification has been valid only with OU and E (ot=
hers have be very rare always). In addition all Telia SSL certificates have=
 always been also post-examined (visually) after the enrollment to be absol=
utely sure that no incorrect subject values have passed our validation (sec=
ond person evaluation).

I understand your opinion that this kind of visual verification is not as s=
trong as technical email verification with random codes. However, random co=
de verification is not written to be required by BR. BR only states in 7.1.=
4.2.2.j: "All other optional attributes, when present within the subject fi=
eld, MUST contain information that has been verified by the CA." In my opin=
ion we have followed that requirement because we have had a verification me=
thod for those values; do you disagree?=20

Next we are ready to stop adding E values completely to solve this issue pe=
rmanently but we think it is not right to require us to revoke all our old =
E values.

0
pekka
8/6/2018 7:28:10 AM
On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> I want to emphasize that each and every value of certificate Subject have
> always been verified. It's wrong to say that those values are unverified.
> It is only a question about E verification method and quality. Our method
> has been to estimate visually by Registration Officer if each E value (or
> other subject value outside common group C,O,ST,L, streetAddress,
> postalCode) is correct for this Customer.
>

What are you visually validating though? That it's an email address? That
it's owned by the Subscriber? By comparison, what does it mean to "visually
validate" one of those other fields - are you using some registration
service? Some form of validation (e.g. sending an email)?

I think it's fair to say that these fields aren't validated, if your
process is just that the RA looks at it and says "sure"


> Registration Officer training has instructed which E values must be
> rejected. It is not possible to use visually similar kinds of characters
> because we technically restrict Subject characters to common ASCII
> characters (e.g. nulls are rejected). It is completely incorrect to claim
> that any values are added  without validation. Since Feb 2018 Telia also
> techically prevents any other values than C,O,L,OU,E,CN from inserted to
> SSL certificates. Since that the simple visual verification has been valid
> only with OU and E (others have be very rare always). In addition all Telia
> SSL certificates have always been also post-examined (visually) after the
> enrollment to be absolutely sure that no incorrect subject values have
> passed our validation (second person evaluation).
>

I think this is really good information - it suggests that prior to Feb
2018, those other fields from the CSR may be copied over.

If it helps, think about something like "Country" or "Organization". Visual
validation just says "Yeah, this is probably right", while actual
validation involves making sure it's a valid ISO country code (in the case
of C) or that the Organization is actually affiliated with the Applicant
(in the case of O). Hopefully that distinction makes it clearer?


> I understand your opinion that this kind of visual verification is not as
> strong as technical email verification with random codes. However, random
> code verification is not written to be required by BR. BR only states in
> 7.1.4.2.2.j: "All other optional attributes, when present within the
> subject field, MUST contain information that has been verified by the CA."
> In my opinion we have followed that requirement because we have had a
> verification method for those values; do you disagree?
>

I think this is the point that I'm trying to understand - what those
verification methods were and how they were assessed to be correct for the
field. We've discussed emailAddress, but it sounds like prior to Feb 2018,
this may have included other fields (besides OU and emailAddress). Have you
examined and reviewed the past certificates for that?


> Next we are ready to stop adding E values completely to solve this issue
> permanently but we think it is not right to require us to revoke all our
> old E values.
>

Why is that? What was actually validated for those emailAddresses? Just
that the RA thought it 'probably' was correct for that Applicant?
0
Ryan
8/7/2018 10:41:10 PM
keskiviikko 8. elokuuta 2018 1.43.39 UTC+3 Ryan Sleevi kirjoitti:
> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-poli=
cy
> <dev-security-policy@lists.mozilla.org> wrote:
>=20
> > I want to emphasize that each and every value of certificate Subject ha=
ve
> > always been verified. It's wrong to say that those values are unverifie=
d.
> > It is only a question about E verification method and quality. Our meth=
od
> > has been to estimate visually by Registration Officer if each E value (=
or
> > other subject value outside common group C,O,ST,L, streetAddress,
> > postalCode) is correct for this Customer.
> >
>=20
> What are you visually validating though? That it's an email address? That
> it's owned by the Subscriber? By comparison, what does it mean to "visual=
ly
> validate" one of those other fields - are you using some registration
> service? Some form of validation (e.g. sending an email)?
>=20
> I think it's fair to say that these fields aren't validated, if your
> process is just that the RA looks at it and says "sure"
>=20
Our CPS has previously defined our E verification process like this: "The R=
egistration Officer is obliged to always review all subject information and=
 initiate additional checking routines if there are any unclear Subject val=
ues. Domain name ownership of domains in email addresses may belong to anot=
her company than the applicant e.g. to some service provider."

We believe that E value is supposed to be Applicant server=E2=80=99s suppor=
t email address. It is hard to for CA to be sure that the provided address =
is exactly such address. In some cases our customers have used personal add=
resses and in some cases service provider addresses. We have accepted both.

Technically we=E2=80=99ve verified that email address follows emailAddress =
format specification. Visually we verify that the email address looks like =
normal support email address for the Applicant. If the verifier=20
can't be sure in the visual verification he/she must escalate the verificat=
ion to our Security team. They will check e.g. that the email address domai=
n is owned by the Applicant or that Applicant confirms the address to be th=
eir support email address. Even though our verification isn't very strong i=
t is a two-phase verification: syntax and visual. Because of the weakness o=
f our method we wanted to open this discussion to understand what BR creato=
rs have meant when they have formulated the E validation requirement using =
only these words "MUST contain information that has been verified by the CA=
", nothing else. And why openssl is using E as a default subject field in i=
ts CSR generation for SSL certificates if that value is not supposed to be =
inserted to SSL certificate. Our interpretation of BR text has been that E =
value verification has no exact requirements and any reasonable verificatio=
n (including our technical&visual verification method) is enough.

>=20
> > Registration Officer training has instructed which E values must be
> > rejected. It is not possible to use visually similar kinds of character=
s
> > because we technically restrict Subject characters to common ASCII
> > characters (e.g. nulls are rejected). It is completely incorrect to cla=
im
> > that any values are added  without validation. Since Feb 2018 Telia als=
o
> > techically prevents any other values than C,O,L,OU,E,CN from inserted t=
o
> > SSL certificates. Since that the simple visual verification has been va=
lid
> > only with OU and E (others have be very rare always). In addition all T=
elia
> > SSL certificates have always been also post-examined (visually) after t=
he
> > enrollment to be absolutely sure that no incorrect subject values have
> > passed our validation (second person evaluation).
> >
>=20
> I think this is really good information - it suggests that prior to Feb
> 2018, those other fields from the CSR may be copied over.
>=20
> If it helps, think about something like "Country" or "Organization". Visu=
al
> validation just says "Yeah, this is probably right", while actual
> validation involves making sure it's a valid ISO country code (in the cas=
e
> of C) or that the Organization is actually affiliated with the Applicant
> (in the case of O). Hopefully that distinction makes it clearer?
>=20
The listed validation examples won't help us very much because the describe=
d C verification is basically the same what we have done in our technical E=
 value verification (that the value is legal). Examples aren't relevant bec=
ause both C and O have quite clear verification specification on BR. E veri=
fication instead has't been properly specified in BR.
>=20
> > I understand your opinion that this kind of visual verification is not =
as
> > strong as technical email verification with random codes. However, rand=
om
> > code verification is not written to be required by BR. BR only states i=
n
> > 7.1.4.2.2.j: "All other optional attributes, when present within the
> > subject field, MUST contain information that has been verified by the C=
A."
> > In my opinion we have followed that requirement because we have had a
> > verification method for those values; do you disagree?
> >
>=20
> I think this is the point that I'm trying to understand - what those
> verification methods were and how they were assessed to be correct for th=
e
> field. We've discussed emailAddress, but it sounds like prior to Feb 2018=
,
> this may have included other fields (besides OU and emailAddress). Have y=
ou
> examined and reviewed the past certificates for that?
>=20
We have now re-verified from CA database that we have never used the descri=
bed weak visual verification to any other field than E and OU.=20
>=20
> > Next we are ready to stop adding E values completely to solve this issu=
e
> > permanently but we think it is not right to require us to revoke all ou=
r
> > old E values.
> >
>=20
> Why is that? What was actually validated for those emailAddresses? Just
> that the RA thought it 'probably' was correct for that Applicant?

Because all our old E values have been verified using the two methods I hav=
e explained in this discussion: both technically and visually. Those method=
s verify that each E value is technically OK (compare this to your C exampl=
e) and each value looks like a proper support email address for that applic=
ant. Our instructions for visual E verification were that the address shoul=
d not look like company name and should not otherwise cause uncertainty.

Verification examples:
Abc =E2=80=93 Rejected by technical Telia E verification (not a valid email=
 address)
Telia@ab =E2=80=93 Rejected by visual Telia E verification (attempt to use =
E value that looks more like O)
casupport@telia.fi =E2=80=93 Accepted by all Telia E verifications=20

If Telia wouldn=E2=80=99t use any E verification all above values were acce=
pted. BR does not specify how E verification should be done so in our opini=
on you cannot reasonably expect us to use any specific other verification m=
ethods. BR text should be modified if only some specific E verification met=
hods were accepted. In our opinion E values aren=E2=80=99t significant for =
the safety of certificates (many browsers hide them anyway) so this change =
to BR text is not necessary. If any modifications are done then PKI communi=
ty should estimate what is the correct required verification level, e.g. E =
won=E2=80=99t look like company name, E is able to give answers, E owner ac=
cepts the value to be used generally in certificates, or only for this appl=
icant, or only for this specific FQDN list, or perhaps that E owner is able=
 to give support. People may have different opinions. In our opinion any me=
thod that may postpone certificate application acceptance is problematic an=
d very few methods are thus suitable in practice.=20



0
pekka
8/10/2018 9:02:59 AM
keskiviikko 8. elokuuta 2018 1.43.39 UTC+3 Ryan Sleevi kirjoitti:
> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-poli=
cy
> <dev-security-policy@lists.mozilla.org> wrote:
>=20
> > I want to emphasize that each and every value of certificate Subject ha=
ve
> > always been verified. It's wrong to say that those values are unverifie=
d.
> > It is only a question about E verification method and quality. Our meth=
od
> > has been to estimate visually by Registration Officer if each E value (=
or
> > other subject value outside common group C,O,ST,L, streetAddress,
> > postalCode) is correct for this Customer.
> >
>=20
> What are you visually validating though? That it's an email address? That
> it's owned by the Subscriber? By comparison, what does it mean to "visual=
ly
> validate" one of those other fields - are you using some registration
> service? Some form of validation (e.g. sending an email)?
>=20
> I think it's fair to say that these fields aren't validated, if your
> process is just that the RA looks at it and says "sure"
>=20
Our CPS has previously defined our E verification process like this: "The R=
egistration Officer is obliged to always review all subject information and=
 initiate additional checking routines if there are any unclear Subject val=
ues. Domain name ownership of domains in email addresses may belong to anot=
her company than the applicant e.g. to some service provider."

We believe that E value is supposed to be Applicant server=E2=80=99s suppor=
t email address. It is very hard to for CA to be sure that the provided add=
ress is exactly such address. In some cases our customers have used persona=
l addresses and in some cases service provider addresses. We have accepted =
both.

Technically we=E2=80=99ve verified that email address follows emailAddress =
format specification. Visually we've verified that the email address look l=
ike normal support email address for the Applicant. If the verifier can't b=
e sure in the visual verification he/she must escalate the verification to =
our Security team. They will check e.g. that the email address domain is ow=
ned by the Applicant or that Applicant confirms the address to be their sup=
port email address. Even though our verification isn't very strong it is a =
two-phase verification: syntax and visual. Because of the weakness of our m=
ethod we wanted to open this discussion to understand what BR creators have=
 meant when they have formulated the E validation requirement using only th=
ese words "MUST contain information that has been verified by the CA", noth=
ing else. And why openssl is using E as a default subject field in its CSR =
generation for SSL certificates if that value is not supposed to be inserte=
d to SSL certificate. Our interpretation of BR text has been that E value v=
erification has no exact requirements and any reasonable verification (incl=
uding our technical&visual verification method) is enough.

>=20
> > Registration Officer training has instructed which E values must be
> > rejected. It is not possible to use visually similar kinds of character=
s
> > because we technically restrict Subject characters to common ASCII
> > characters (e.g. nulls are rejected). It is completely incorrect to cla=
im
> > that any values are added  without validation. Since Feb 2018 Telia als=
o
> > techically prevents any other values than C,O,L,OU,E,CN from inserted t=
o
> > SSL certificates. Since that the simple visual verification has been va=
lid
> > only with OU and E (others have be very rare always). In addition all T=
elia
> > SSL certificates have always been also post-examined (visually) after t=
he
> > enrollment to be absolutely sure that no incorrect subject values have
> > passed our validation (second person evaluation).
> >
>=20
> I think this is really good information - it suggests that prior to Feb
> 2018, those other fields from the CSR may be copied over.
>=20
> If it helps, think about something like "Country" or "Organization". Visu=
al
> validation just says "Yeah, this is probably right", while actual
> validation involves making sure it's a valid ISO country code (in the cas=
e
> of C) or that the Organization is actually affiliated with the Applicant
> (in the case of O). Hopefully that distinction makes it clearer?
>=20
The listed validation examples won't help us very much because the describe=
d C verification is basically the same what we have done in our technical E=
 value verification (that the value is legal). Examples aren't relevant bec=
ause both C and O have quite clear verification specification on BR. E veri=
fication instead has't been properly specified in BR.
>=20
> > I understand your opinion that this kind of visual verification is not =
as
> > strong as technical email verification with random codes. However, rand=
om
> > code verification is not written to be required by BR. BR only states i=
n
> > 7.1.4.2.2.j: "All other optional attributes, when present within the
> > subject field, MUST contain information that has been verified by the C=
A."
> > In my opinion we have followed that requirement because we have had a
> > verification method for those values; do you disagree?
> >
>=20
> I think this is the point that I'm trying to understand - what those
> verification methods were and how they were assessed to be correct for th=
e
> field. We've discussed emailAddress, but it sounds like prior to Feb 2018=
,
> this may have included other fields (besides OU and emailAddress). Have y=
ou
> examined and reviewed the past certificates for that?
>=20
We have now re-verified from CA database that we have never used the descri=
bed visual verification to any other field than E and OU.=20
>=20
> > Next we are ready to stop adding E values completely to solve this issu=
e
> > permanently but we think it is not right to require us to revoke all ou=
r
> > old E values.
> >
>=20
> Why is that? What was actually validated for those emailAddresses? Just
> that the RA thought it 'probably' was correct for that Applicant?

Because all our old E values have been verified using the two methods I hav=
e explained in this discussion: both technically and visually. Those method=
s verify that each E value is technically OK (compare this to your C exampl=
e) and each value looks like a proper support email address for that applic=
ant. Our instructions for visual E verification were that the address shoul=
d not look like company name and should not otherwise cause uncertainty.

Verification examples:
Abc =E2=80=93 Rejected by technical Telia E verification (not a valid email=
 address)
Telia@ab =E2=80=93 Rejected by visual Telia E verification (attempt to use =
E value that looks more like O)
support@telia.fi =E2=80=93 Accepted by all Telia E verifications

BR does not specify how E verification should be done so in our opinion you=
 cannot reasonably expect us to use any specific other verification methods=
.. BR text should be modified if only some specific E verification methods w=
ere accepted. In our opinion E values aren=E2=80=99t significant for the sa=
fety of certificates (many browsers hide them anyway) so this change to BR =
text is not necessary. If any modifications are done then PKI community sho=
uld estimate what is the correct required verification level, e.g. E won=E2=
=80=99t look like company name, company owns the domain, E is able to give =
answers, E owner accepts the value to be used generally in certificates, or=
 only for this applicant, or only for this specific FQDN list, or perhaps t=
hat E owner is able to give support. People may have different opinions. In=
 our opinion any method that may delay certificate application acceptance i=
s problematic and very few methods are thus suitable in practice.=20


0
pekka
8/10/2018 10:44:26 AM
> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-poli=
cy
> <dev-security-policy@lists.mozilla.org> wrote:
>=20
> > I want to emphasize that each and every value of certificate Subject ha=
ve
> > always been verified. It's wrong to say that those values are unverifie=
d.
> > It is only a question about E verification method and quality. Our meth=
od
> > has been to estimate visually by Registration Officer if each E value (=
or
> > other subject value outside common group C,O,ST,L, streetAddress,
> > postalCode) is correct for this Customer.
> >
>=20
> What are you visually validating though? That it's an email address? That
> it's owned by the Subscriber? By comparison, what does it mean to "visual=
ly
> validate" one of those other fields - are you using some registration
> service? Some form of validation (e.g. sending an email)?
>=20
> I think it's fair to say that these fields aren't validated, if your
> process is just that the RA looks at it and says "sure"
>=20
Our CPS has previously defined our E verification process like this: "The R=
egistration Officer is obliged to always review all subject information and=
 initiate additional checking routines if there are any unclear Subject val=
ues. Domain name ownership of domains in email addresses may belong to anot=
her company than the applicant e.g. to some service provider."

We believe that E value is supposed to be Applicant server=E2=80=99s suppor=
t email address. It is very hard to for CA to be sure that the provided add=
ress is exactly such address. In some cases our customers have used persona=
l addresses and in some cases service provider addresses. We have accepted =
both.

Technically we=E2=80=99ve verified that email address follows emailAddress =
format specification. Visually we verify that the email address look like n=
ormal support email address for the Applicant. If the verifier=20
can't be sure in the visual verification he/she must escalate the verificat=
ion to our Security team. They will check e.g. that the email address domai=
n is owned by the Applicant or that Applicant confirms the address to be th=
eir support email address. Even though our verification isn't very strong i=
t is a two-phase verification: syntax and visual. Because of the weakness o=
f our method we wanted to open this discussion to understand what BR creato=
rs have meant when they have formulated the E validation requirement using =
only these words "MUST contain information that has been verified by the CA=
", nothing else. And why openssl is using E as a default subject field in i=
ts CSR generation for SSL certificates if that value is not supposed to be =
inserted to SSL certificate. Our interpretation of BR text has been that E =
value verification has no exact requirements and any reasonable verificatio=
n (including our technical&visual verification method) is enough.
>=20
> > Registration Officer training has instructed which E values must be
> > rejected. It is not possible to use visually similar kinds of character=
s
> > because we technically restrict Subject characters to common ASCII
> > characters (e.g. nulls are rejected). It is completely incorrect to cla=
im
> > that any values are added  without validation. Since Feb 2018 Telia als=
o
> > techically prevents any other values than C,O,L,OU,E,CN from inserted t=
o
> > SSL certificates. Since that the simple visual verification has been va=
lid
> > only with OU and E (others have be very rare always). In addition all T=
elia
> > SSL certificates have always been also post-examined (visually) after t=
he
> > enrollment to be absolutely sure that no incorrect subject values have
> > passed our validation (second person evaluation).
> >
>=20
> I think this is really good information - it suggests that prior to Feb
> 2018, those other fields from the CSR may be copied over.
>=20
> If it helps, think about something like "Country" or "Organization". Visu=
al
> validation just says "Yeah, this is probably right", while actual
> validation involves making sure it's a valid ISO country code (in the cas=
e
> of C) or that the Organization is actually affiliated with the Applicant
> (in the case of O). Hopefully that distinction makes it clearer?
>=20
The listed validation examples won't help us very much because the describe=
d C verification is basically the same what we have done in our technical E=
 value verification (that the value is legal). Examples aren't relevant bec=
ause both C and O have quite clear verification specification on BR. E veri=
fication instead has't been properly specified in BR.

>=20
> > I understand your opinion that this kind of visual verification is not =
as
> > strong as technical email verification with random codes. However, rand=
om
> > code verification is not written to be required by BR. BR only states i=
n
> > 7.1.4.2.2.j: "All other optional attributes, when present within the
> > subject field, MUST contain information that has been verified by the C=
A."
> > In my opinion we have followed that requirement because we have had a
> > verification method for those values; do you disagree?
> >
>=20
> I think this is the point that I'm trying to understand - what those
> verification methods were and how they were assessed to be correct for th=
e
> field. We've discussed emailAddress, but it sounds like prior to Feb 2018=
,
> this may have included other fields (besides OU and emailAddress). Have y=
ou
> examined and reviewed the past certificates for that?
>=20
We have now re-verified from CA database that we have never used the descri=
bed weak visual verification to any other field than E and OU.=20
>=20
> > Next we are ready to stop adding E values completely to solve this issu=
e
> > permanently but we think it is not right to require us to revoke all ou=
r
> > old E values.
> >
>=20
> Why is that? What was actually validated for those emailAddresses? Just
> that the RA thought it 'probably' was correct for that Applicant?
Because all our old E values have been verified using the two methods I hav=
e explained in this discussion: both technically and visually. Those method=
s verify that each E value is technically OK (compare this to your C exampl=
e) and each value looks like a proper support email address for that applic=
ant. Our instructions for visual E verification were that the address shoul=
d not look like company name and should not otherwise cause uncertainty.

Verification examples:
Abc =E2=80=93 Rejected by technical Telia E verification (not a valid email=
 address)
Telia@ab =E2=80=93 Rejected by visual Telia E verification (attempt to use =
E value that looks more like O)
support@telia.fi =E2=80=93 Accepted by all Telia E verifications

BR does not specify how E verification should be done so in our opinion you=
 cannot reasonably expect us to use any specific other verification methods=
.. BR text should be modified if only some specific E verification methods  =
were accepted. In our opinion E values aren=E2=80=99t significant for the s=
afety of certificates (many browsers hide them anyway) so this change to BR=
 text is not necessary. If any modifications are done then PKI community sh=
ould estimate what is the correct required verification level, e.g. E won=
=E2=80=99t look like company name, E domain is owned by the company, E is a=
ble to give answers, E owner accepts the value to be used generally in cert=
ificates, or only for this applicant, or only for this specific FQDN list, =
or perhaps that E owner is able to give support. People may have different =
opinions. In our opinion any method that may delay certificate application =
acceptance is problematic and very few methods are thus suitable in practic=
e.=20

0
pekka
8/10/2018 11:00:21 AM
> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-poli=
cy
> <dev-security-policy@lists.mozilla.org> wrote:
>=20
> > I want to emphasize that each and every value of certificate Subject ha=
ve
> > always been verified. It's wrong to say that those values are unverifie=
d.
> > It is only a question about E verification method and quality. Our meth=
od
> > has been to estimate visually by Registration Officer if each E value (=
or
> > other subject value outside common group C,O,ST,L, streetAddress,
> > postalCode) is correct for this Customer.
> >
>=20
> What are you visually validating though? That it's an email address? That
> it's owned by the Subscriber? By comparison, what does it mean to "visual=
ly
> validate" one of those other fields - are you using some registration
> service? Some form of validation (e.g. sending an email)?
>=20
> I think it's fair to say that these fields aren't validated, if your
> process is just that the RA looks at it and says "sure"
>=20
Our CPS has previously defined our E verification process like this: "The R=
egistration Officer is obliged to always review all subject information and=
 initiate additional checking routines if there are any unclear Subject val=
ues. Domain name ownership of domains in email addresses may belong to anot=
her company than the applicant e.g. to some service provider."

We believe that E value is supposed to be Applicant server=E2=80=99s suppor=
t email address. It is very hard to for CA to be sure that the provided add=
ress is exactly such address. In some cases our customers have used persona=
l addresses and in some cases service provider addresses. We have accepted =
both.

Technically we=E2=80=99ve verified that email address follows emailAddress =
format specification. Visually we verify that the email address look like n=
ormal support email address for the Applicant. If the verifier=20
can't be sure in the visual verification he/she must escalate the verificat=
ion to our Security team. They will check e.g. that the email address domai=
n is owned by the Applicant or that Applicant confirms the address to be th=
eir support email address. Even though our verification isn't very strong i=
t is a two-phase verification: syntax and visual. Because of the weakness o=
f our method we wanted to open this discussion to understand what BR creato=
rs have meant when they have formulated the E validation requirement using =
only these words "MUST contain information that has been verified by the CA=
", nothing else. And why openssl is using E as a default subject field in i=
ts CSR generation for SSL certificates if that value is not supposed to be =
inserted to SSL certificate. Our interpretation of BR text has been that E =
value verification has no exact requirements and any reasonable verificatio=
n (including our technical&visual verification method) is enough.
>=20
> > Registration Officer training has instructed which E values must be
> > rejected. It is not possible to use visually similar kinds of character=
s
> > because we technically restrict Subject characters to common ASCII
> > characters (e.g. nulls are rejected). It is completely incorrect to cla=
im
> > that any values are added  without validation. Since Feb 2018 Telia als=
o
> > techically prevents any other values than C,O,L,OU,E,CN from inserted t=
o
> > SSL certificates. Since that the simple visual verification has been va=
lid
> > only with OU and E (others have be very rare always). In addition all T=
elia
> > SSL certificates have always been also post-examined (visually) after t=
he
> > enrollment to be absolutely sure that no incorrect subject values have
> > passed our validation (second person evaluation).
> >
>=20
> I think this is really good information - it suggests that prior to Feb
> 2018, those other fields from the CSR may be copied over.
>=20
> If it helps, think about something like "Country" or "Organization". Visu=
al
> validation just says "Yeah, this is probably right", while actual
> validation involves making sure it's a valid ISO country code (in the cas=
e
> of C) or that the Organization is actually affiliated with the Applicant
> (in the case of O). Hopefully that distinction makes it clearer?
>=20
The listed validation examples won't help us very much because the describe=
d C verification is basically the same what we have done in our technical E=
 value verification (that the value is legal). Examples aren't relevant bec=
ause both C and O have quite clear verification specification on BR. E veri=
fication instead has't been properly specified in BR.

>=20
> > I understand your opinion that this kind of visual verification is not =
as
> > strong as technical email verification with random codes. However, rand=
om
> > code verification is not written to be required by BR. BR only states i=
n
> > 7.1.4.2.2.j: "All other optional attributes, when present within the
> > subject field, MUST contain information that has been verified by the C=
A."
> > In my opinion we have followed that requirement because we have had a
> > verification method for those values; do you disagree?
> >
>=20
> I think this is the point that I'm trying to understand - what those
> verification methods were and how they were assessed to be correct for th=
e
> field. We've discussed emailAddress, but it sounds like prior to Feb 2018=
,
> this may have included other fields (besides OU and emailAddress). Have y=
ou
> examined and reviewed the past certificates for that?
>=20
We have now re-verified from CA database that we have never used the descri=
bed weak visual verification to any other field than E and OU.=20
>=20
> > Next we are ready to stop adding E values completely to solve this issu=
e
> > permanently but we think it is not right to require us to revoke all ou=
r
> > old E values.
> >
>=20
> Why is that? What was actually validated for those emailAddresses? Just
> that the RA thought it 'probably' was correct for that Applicant?
Because all our old E values have been verified using the two methods I hav=
e explained in this discussion: both technically and visually. Those method=
s verify that each E value is technically OK (compare this to your C exampl=
e) and each value looks like a proper support email address for that applic=
ant. Our instructions for visual E verification were that the address shoul=
d not look like company name and should not otherwise cause uncertainty.

Verification examples:
Abc =E2=80=93 Rejected by technical Telia E verification (not a valid email=
 address)
Telia@ab =E2=80=93 Rejected by visual Telia E verification (attempt to use =
E value that looks more like O)
support@telia.fi =E2=80=93 Accepted by all Telia E verifications

BR does not specify how E verification should be done so in our opinion you=
 cannot reasonably expect us to use any specific other verification methods=
.. BR text should be modified if only some specific E verification methods  =
were accepted. In our opinion E values aren=E2=80=99t significant for the s=
afety of certificates (many browsers hide them anyway) so this change to BR=
 text is not necessary. If any modifications are done then PKI community sh=
ould estimate what is the correct required verification level, e.g. E won=
=E2=80=99t look like company name, E domain is owned by the company, E is a=
ble to give answers, E owner accepts the value to be used generally in cert=
ificates, or only for this applicant, or only for this specific FQDN list, =
or perhaps that E owner is able to give support. People may have different =
opinions. In our opinion any method that may delay certificate application =
acceptance is problematic and very few methods are thus suitable in practic=
e.=20

0
pekka
8/10/2018 11:02:47 AM
> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-poli=
cy
> <dev-security-policy@lists.mozilla.org> wrote:
>=20
> > I want to emphasize that each and every value of certificate Subject ha=
ve
> > always been verified. It's wrong to say that those values are unverifie=
d.
> > It is only a question about E verification method and quality. Our meth=
od
> > has been to estimate visually by Registration Officer if each E value (=
or
> > other subject value outside common group C,O,ST,L, streetAddress,
> > postalCode) is correct for this Customer.
> >
>=20
> What are you visually validating though? That it's an email address? That
> it's owned by the Subscriber? By comparison, what does it mean to "visual=
ly
> validate" one of those other fields - are you using some registration
> service? Some form of validation (e.g. sending an email)?
>=20
> I think it's fair to say that these fields aren't validated, if your
> process is just that the RA looks at it and says "sure"
>=20
Our CPS has previously defined our E verification process like this: "The R=
egistration Officer is obliged to always review all subject information and=
 initiate additional checking routines if there are any unclear Subject val=
ues. Domain name ownership of domains in email addresses may belong to anot=
her company than the applicant e.g. to some service provider."

We believe that E value is supposed to be Applicant server=E2=80=99s suppor=
t email address. It is very hard to for CA to be sure that the provided add=
ress is exactly such address. In some cases our customers have used persona=
l addresses and in some cases service provider addresses. We have accepted =
both.

Technically we=E2=80=99ve verified that email address follows emailAddress =
format specification. Visually we verify that the email address look like n=
ormal support email address for the Applicant. If the verifier=20
can't be sure in the visual verification he/she must escalate the verificat=
ion to our Security team. They will check e.g. that the email address domai=
n is owned by the Applicant or that Applicant confirms the address to be th=
eir support email address. Even though our verification isn't very strong i=
t is a two-phase verification: syntax and visual. Because of the weakness o=
f our method we wanted to open this discussion to understand what BR creato=
rs have meant when they have formulated the E validation requirement using =
only these words "MUST contain information that has been verified by the CA=
", nothing else. And why openssl is using E as a default subject field in i=
ts CSR generation for SSL certificates if that value is not supposed to be =
inserted to SSL certificate. Our interpretation of BR text has been that E =
value verification has no exact requirements and any reasonable verificatio=
n (including our technical&visual verification method) is enough.
>=20
> > Registration Officer training has instructed which E values must be
> > rejected. It is not possible to use visually similar kinds of character=
s
> > because we technically restrict Subject characters to common ASCII
> > characters (e.g. nulls are rejected). It is completely incorrect to cla=
im
> > that any values are added  without validation. Since Feb 2018 Telia als=
o
> > techically prevents any other values than C,O,L,OU,E,CN from inserted t=
o
> > SSL certificates. Since that the simple visual verification has been va=
lid
> > only with OU and E (others have be very rare always). In addition all T=
elia
> > SSL certificates have always been also post-examined (visually) after t=
he
> > enrollment to be absolutely sure that no incorrect subject values have
> > passed our validation (second person evaluation).
> >
>=20
> I think this is really good information - it suggests that prior to Feb
> 2018, those other fields from the CSR may be copied over.
>=20
> If it helps, think about something like "Country" or "Organization". Visu=
al
> validation just says "Yeah, this is probably right", while actual
> validation involves making sure it's a valid ISO country code (in the cas=
e
> of C) or that the Organization is actually affiliated with the Applicant
> (in the case of O). Hopefully that distinction makes it clearer?
>=20
The listed validation examples won't help us very much because the describe=
d C verification is basically the same what we have done in our technical E=
 value verification (that the value is legal). Examples aren't relevant bec=
ause both C and O have quite clear verification specification on BR. E veri=
fication instead has't been properly specified in BR.

>=20
> > I understand your opinion that this kind of visual verification is not =
as
> > strong as technical email verification with random codes. However, rand=
om
> > code verification is not written to be required by BR. BR only states i=
n
> > 7.1.4.2.2.j: "All other optional attributes, when present within the
> > subject field, MUST contain information that has been verified by the C=
A."
> > In my opinion we have followed that requirement because we have had a
> > verification method for those values; do you disagree?
> >
>=20
> I think this is the point that I'm trying to understand - what those
> verification methods were and how they were assessed to be correct for th=
e
> field. We've discussed emailAddress, but it sounds like prior to Feb 2018=
,
> this may have included other fields (besides OU and emailAddress). Have y=
ou
> examined and reviewed the past certificates for that?
>=20
We have now re-verified from CA database that we have never used the descri=
bed weak visual verification to any other field than E and OU.=20
>=20
> > Next we are ready to stop adding E values completely to solve this issu=
e
> > permanently but we think it is not right to require us to revoke all ou=
r
> > old E values.
> >
>=20
> Why is that? What was actually validated for those emailAddresses? Just
> that the RA thought it 'probably' was correct for that Applicant?
Because all our old E values have been verified using the two methods I hav=
e explained in this discussion: both technically and visually. Those method=
s verify that each E value is technically OK (compare this to your C exampl=
e) and each value looks like a proper support email address for that applic=
ant. Our instructions for visual E verification were that the address shoul=
d not look like company name and should not otherwise cause uncertainty.

Verification examples:
Abc =E2=80=93 Rejected by technical Telia E verification (not a valid email=
 address)
Telia@ab =E2=80=93 Rejected by visual Telia E verification (attempt to use =
E value that looks more like O)
support@telia.fi =E2=80=93 Accepted by all Telia E verifications

BR does not specify how E verification should be done so in our opinion you=
 cannot reasonably expect us to use any specific other verification methods=
.. BR text should be modified if only some specific E verification methods  =
were accepted. In our opinion E values aren=E2=80=99t significant for the s=
afety of certificates (many browsers hide them anyway) so this change to BR=
 text is not necessary. If any modifications are done then PKI community sh=
ould estimate what is the correct required verification level, e.g. E won=
=E2=80=99t look like company name, E domain is owned by the company, E is a=
ble to give answers, E owner accepts the value to be used generally in cert=
ificates, or only for this applicant, or only for this specific FQDN list, =
or perhaps that E owner is able to give support. People may have different =
opinions. In our opinion any method that may delay certificate application =
acceptance is problematic and very few methods are thus suitable in practic=
e.=20

0
pekka
8/10/2018 11:11:20 AM
On 10/08/2018 13:02, pekka.lahtiharju@teliasonera.com wrote:
>> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
>> <dev-security-policy@lists.mozilla.org> wrote:
>>
>>> I want to emphasize that each and every value of certificate Subject have
>>> always been verified. It's wrong to say that those values are unverified.
>>> It is only a question about E verification method and quality. Our method
>>> has been to estimate visually by Registration Officer if each E value (or
>>> other subject value outside common group C,O,ST,L, streetAddress,
>>> postalCode) is correct for this Customer.
>>>
>>
>> What are you visually validating though? That it's an email address? That
>> it's owned by the Subscriber? By comparison, what does it mean to "visually
>> validate" one of those other fields - are you using some registration
>> service? Some form of validation (e.g. sending an email)?
>>
>> I think it's fair to say that these fields aren't validated, if your
>> process is just that the RA looks at it and says "sure"
>>
> Our CPS has previously defined our E verification process like this: "The Registration Officer is obliged to always review all subject information and initiate additional checking routines if there are any unclear Subject values. Domain name ownership of domains in email addresses may belong to another company than the applicant e.g. to some service provider."
> 
> We believe that E value is supposed to be Applicant server’s support email address. It is very hard to for CA to be sure that the provided address is exactly such address. In some cases our customers have used personal addresses and in some cases service provider addresses. We have accepted both.
> 
> Technically we’ve verified that email address follows emailAddress format specification. Visually we verify that the email address look like normal support email address for the Applicant. If the verifier
> can't be sure in the visual verification he/she must escalate the verification to our Security team. They will check e.g. that the email address domain is owned by the Applicant or that Applicant confirms the address to be their support email address. Even though our verification isn't very strong it is a two-phase verification: syntax and visual. Because of the weakness of our method we wanted to open this discussion to understand what BR creators have meant when they have formulated the E validation requirement using only these words "MUST contain information that has been verified by the CA", nothing else. And why openssl is using E as a default subject field in its CSR generation for SSL certificates if that value is not supposed to be inserted to SSL certificate. Our interpretation of BR text has been that E value verification has no exact requirements and any reasonable verification (including our technical&visual verification method) is enough.
>>
>>> Registration Officer training has instructed which E values must be
>>> rejected. It is not possible to use visually similar kinds of characters
>>> because we technically restrict Subject characters to common ASCII
>>> characters (e.g. nulls are rejected). It is completely incorrect to claim
>>> that any values are added  without validation. Since Feb 2018 Telia also
>>> techically prevents any other values than C,O,L,OU,E,CN from inserted to
>>> SSL certificates. Since that the simple visual verification has been valid
>>> only with OU and E (others have be very rare always). In addition all Telia
>>> SSL certificates have always been also post-examined (visually) after the
>>> enrollment to be absolutely sure that no incorrect subject values have
>>> passed our validation (second person evaluation).
>>>
>>
>> I think this is really good information - it suggests that prior to Feb
>> 2018, those other fields from the CSR may be copied over.
>>
>> If it helps, think about something like "Country" or "Organization". Visual
>> validation just says "Yeah, this is probably right", while actual
>> validation involves making sure it's a valid ISO country code (in the case
>> of C) or that the Organization is actually affiliated with the Applicant
>> (in the case of O). Hopefully that distinction makes it clearer?
>>
> The listed validation examples won't help us very much because the described C verification is basically the same what we have done in our technical E value verification (that the value is legal). Examples aren't relevant because both C and O have quite clear verification specification on BR. E verification instead has't been properly specified in BR.
> 
>>
>>> I understand your opinion that this kind of visual verification is not as
>>> strong as technical email verification with random codes. However, random
>>> code verification is not written to be required by BR. BR only states in
>>> 7.1.4.2.2.j: "All other optional attributes, when present within the
>>> subject field, MUST contain information that has been verified by the CA."
>>> In my opinion we have followed that requirement because we have had a
>>> verification method for those values; do you disagree?
>>>
>>
>> I think this is the point that I'm trying to understand - what those
>> verification methods were and how they were assessed to be correct for the
>> field. We've discussed emailAddress, but it sounds like prior to Feb 2018,
>> this may have included other fields (besides OU and emailAddress). Have you
>> examined and reviewed the past certificates for that?
>>
> We have now re-verified from CA database that we have never used the described weak visual verification to any other field than E and OU.
>>
>>> Next we are ready to stop adding E values completely to solve this issue
>>> permanently but we think it is not right to require us to revoke all our
>>> old E values.
>>>
>>
>> Why is that? What was actually validated for those emailAddresses? Just
>> that the RA thought it 'probably' was correct for that Applicant?
> Because all our old E values have been verified using the two methods I have explained in this discussion: both technically and visually. Those methods verify that each E value is technically OK (compare this to your C example) and each value looks like a proper support email address for that applicant. Our instructions for visual E verification were that the address should not look like company name and should not otherwise cause uncertainty.
> 
> Verification examples:
> Abc – Rejected by technical Telia E verification (not a valid email address)
> Telia@ab – Rejected by visual Telia E verification (attempt to use E value that looks more like O)
> support@telia.fi – Accepted by all Telia E verifications
> 
> BR does not specify how E verification should be done so in our opinion you cannot reasonably expect us to use any specific other verification methods. BR text should be modified if only some specific E verification methods  were accepted. In our opinion E values aren’t significant for the safety of certificates (many browsers hide them anyway) so this change to BR text is not necessary. If any modifications are done then PKI community should estimate what is the correct required verification level, e.g. E won’t look like company name, E domain is owned by the company, E is able to give answers, E owner accepts the value to be used generally in certificates, or only for this applicant, or only for this specific FQDN list, or perhaps that E owner is able to give support. People may have different opinions. In our opinion any method that may delay certificate application acceptance is problematic and very few methods are thus suitable in practice.
> 

This doesn't even try to validate that the E value is factually *true*,
which is the entire point of a certificate (all signed fields have been
verified as true).  The field with the weakest requirement is the OU
value, here it is often enough to validate that the applicant as an
organization has the inherent authority to define its own organizational
units in almost any way that isn't outright deceptive.

A common validation technique (but not the only one possible) is for the
e-mails regarding issuance, issuance questions etc. to be sent to that
e-mail address.  With CT logging active, something more needs to be done
to ensure the applicant actually receives such e-mails and doesn't just
grab the issued certificate from the CT log or some other alternative
means.

Examples of how other fields are commonly validated (some are explicitly
specified in the BRs or Mozilla policies, others are just covered by the
general rule of validated truth):

Certificate serial number, issuer distinguished name, certificate
signing algorithm, policy OID:  Known first hand (and chosen) by the CA.

Subject public key: Applicant has proven possession of the matching
private key by signing a CSR with it.  CA validates that it is
mathematically sound (key length, numerical properties, encoding etc.).

Each DNSName SANs: Applicant has proven actual control over the DNS
contents and/or a web server on that address.

Each IPAddress SANs: Applicant has proven actual control over a web
server on that globally routable address.

Country: Applicant is actually located in that country and other
location fields are validated within the context of that country.

JurisdictionOfIncorporation: Official records show that applicant is an
actual company or other organization formally created in that
jurisdiction (even if not located there).  For example, ABB may be
formally incorporated in Switzerland (CH), but the certificate is for a
division in Denmark (country=DK).

Serial Number name element: Official records show that this is the
official company registration number in its JurisdictionOfIncorporation.

Location and Street address: Official records show that the organization
is actually located there and/or PostNord can deliver a letter or
package with a confirmation code of some kind to the organization at
that address, and/or the organization similarly receives a phone call on
a land line which Telia has themselves installed at that physical
address, and which Telia internal data confirms isn't being forwarded to
a different location during that call.

Organization Name: Official records confirm that this is the legal name,
plus/minus a CPS enumerated list of notational variations such as
writing ae, aa, oe instead of äåö omitting the AB suffix of a company
etc.

Common Name: For SSL/TLS certificates, this should be a copy of one of
the DNSName SANs, Plus/minus the ongoing debate if this must be the
punycode or standard encoding of an IDNA name.  For e-mail certificates
issued to natural persons, this should be their legal name, again
subject to some notational variations enumerated in the CPS.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
0
Jakob
8/10/2018 12:47:38 PM
In our implementation E value in our certificates was "true" if it passed o=
ur technical and visual verification. If the BR requirement is to do "any" =
verification for E then the verification techniques we used should be OK. W=
e think that BR has meant that both OU and E are based on values defined by=
 Applicant and it is not mandatory to do any email send/response verificati=
on. How do you conclude that BR words "has been verified by the CA" actuall=
y means that some email has to be sent? In our opinion E is just a support =
email address and its verification is not similar to important subject fiel=
ds like O,L or C but can be compared to OU verification.
0
pekka
8/20/2018 8:06:06 AM
On Mon, Aug 20, 2018 at 4:06 AM, pekka.lahtiharju--- via
dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:

> In our implementation E value in our certificates was "true" if it passed
> our technical and visual verification. If the BR requirement is to do "any"
> verification for E then the verification techniques we used should be OK.
> We think that BR has meant that both OU and E are based on values defined
> by Applicant and it is not mandatory to do any email send/response
> verification. How do you conclude that BR words "has been verified by the
> CA" actually means that some email has to be sent? In our opinion E is just
> a support email address and its verification is not similar to important
> subject fields like O,L or C but can be compared to OU verification.


The BRs exclusively detail, with only one exception, how to ensure the
information presented in the certificate is accurate (c.f. 7.1.4.2), and
that the information is factual (c.f. 4.2.1) and with a verification
process (c.f. 3.2.2).

Could you describe where in your CP/CPS your procedures for email
validation were documented?
0
Ryan
8/20/2018 1:49:38 PM
On 20/08/2018 10:06, pekka.lahtiharju@teliasonera.com wrote:
> In our implementation E value in our certificates was "true" if it passed our technical and visual verification. If the BR requirement is to do "any" verification for E then the verification techniques we used should be OK. We think that BR has meant that both OU and E are based on values defined by Applicant and it is not mandatory to do any email send/response verification. How do you conclude that BR words "has been verified by the CA" actually means that some email has to be sent? In our opinion E is just a support email address and its verification is not similar to important subject fields like O,L or C but can be compared to OU verification.
> 

This is a basic X.509 and certificate concept, I have not checked if
the BRs specifically mention requirements for the "e-mail" field in
distinguished names in TLS certificates.

But validation must, as a matter of 1st principles, be an actual
validation, not some person going "looks fine".

Remember, every certificate is the CA (in this case Telia) signing a
statement to the world at large that "We, Telia-Sonera AB, hereby swear
that we have verified every fact here stated to the best of our ability,
and you can rely on these facts without doing any checking of your own".

The BRs merely add specific requirements for CAB/F browser members to
consider a CA operation to be good enough that their browser will be
configured to trust that CA for any end-user not manually overriding
that decision.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
0
Jakob
8/21/2018 12:17:41 AM
In my opinion we follow BR. Here is why:  I think that the first chapter of=
  7.1.4.2 it says that "...CA represents it followed the procedure set fort=
h in its Certificate Policy and/or Certification Practice Statement to veri=
fy...". That is exactly what we do because we have explained in our CPS how=
 E is verified (check below). Perhaps the process description in CPS could =
be better but anyway the descriptions are there including the fact that ema=
il (domain) ownership hasn't been always verified. More detailed E process =
description has been in this discussion.

Then BR 7.1.4.2.j specifies how E should be verified for SSL certificates: =
=20

"All other optional attributes, when present within the subject field, MUST=
 contain information that has
been verified by the CA. Optional attributes MUST NOT contain metadata such=
 as =E2=80=98.=E2=80=99, =E2=80=98-=E2=80=98, and =E2=80=98 =E2=80=98 (i.e.=
 space)
characters, and/or any other indication that the value is absent, incomplet=
e, or not applicable."

In our opinion we follow also completely that chapter because we do two kin=
d of verifications to E values and also we prevent meta data values like re=
quired. Note that it is not prohibited in BR text to use our methods. I sti=
ll can't understand what is the exact BR detail that hasn't been followed b=
y us? We haven't verified everything (specifically E) perfectly but we have=
 followed our CPS and our E process has been written to be compatible to cu=
rrent BR 7.1.4.2.j.

Our current CPS v2.1 has E verification documentation mostly in chapter "3.=
2.4 Non-verified Subscriber Information" and partly in 3.2.2. Our CPS is he=
re https://repository.trust.teliasonera.com/Telia_Server_Certificate_CPS_v2=
..1.pdf. Relevant parts of it are copied below:

---
3.2.2: Other subject values like OU or E are verified each time separately.=
=20
3.2.4: The Registration Officer is obliged to always review all subject inf=
ormation and initiate additional checking routines if there are any unclear=
 Subject values....
....Domain name ownership of domains in email addresses may belong to anothe=
r company than the applicant e.g. to some service provider

Note! We have now changed the CPS text into upcoming v2.2 because we comple=
tely stopped adding E values to certificates because our old methods have c=
aused these discussions and E is not mandatory for Customers.

In my opinion E value requirements in BR are much more like weak OU process=
 than any of the strict processes. And that is how it should be because the=
re is no sense to require company support teams to accept each of your OV c=
ertificate but the current hostmaster acceptance related to SAN domains is =
enough.
0
pekka
8/21/2018 8:53:10 AM
Dear Pekka,

"verified by the CA" seems to be the weak point here. What does 
"verified by the CA" mean?

The community seems to interpret this as actions by the CA to verify 
that the information requested to be included in the certificate by the 
Applicant, is actually real and owned/controlled by the Applicant. As 
others already mentioned, CAs usually follow some kind of 
challenge-response process to prove that the email address is real and 
owned/controlled by the Applicant.

You seem to interpret this as "our RA officers look at the address that 
the Applicant requested to be included in the certificate and if it 
appears to have a correct email address syntax (something followed by an 
'@' and then a domain), accept it and include it in the certificate". Is 
this an accurate description of your process? If someone requested a 
Certificate to include "pekka.lahtiharju@teliasonera.com", which seems 
like a legitimate email address, wouldn't you approve it? If not, why not?


Dimitris.



On 21/8/2018 11:53 πμ, pekka.lahtiharju--- via dev-security-policy wrote:
> In my opinion we follow BR. Here is why:  I think that the first chapter of  7.1.4.2 it says that "...CA represents it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify...". That is exactly what we do because we have explained in our CPS how E is verified (check below). Perhaps the process description in CPS could be better but anyway the descriptions are there including the fact that email (domain) ownership hasn't been always verified. More detailed E process description has been in this discussion.
>
> Then BR 7.1.4.2.j specifies how E should be verified for SSL certificates:
>
> "All other optional attributes, when present within the subject field, MUST contain information that has
> been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. space)
> characters, and/or any other indication that the value is absent, incomplete, or not applicable."
>
> In our opinion we follow also completely that chapter because we do two kind of verifications to E values and also we prevent meta data values like required. Note that it is not prohibited in BR text to use our methods. I still can't understand what is the exact BR detail that hasn't been followed by us? We haven't verified everything (specifically E) perfectly but we have followed our CPS and our E process has been written to be compatible to current BR 7.1.4.2.j.
>
> Our current CPS v2.1 has E verification documentation mostly in chapter "3.2.4 Non-verified Subscriber Information" and partly in 3.2.2. Our CPS is here https://repository.trust.teliasonera.com/Telia_Server_Certificate_CPS_v2.1.pdf. Relevant parts of it are copied below:
>
> ---
> 3.2.2: Other subject values like OU or E are verified each time separately.
> 3.2.4: The Registration Officer is obliged to always review all subject information and initiate additional checking routines if there are any unclear Subject values....
> ...Domain name ownership of domains in email addresses may belong to another company than the applicant e.g. to some service provider
>
> Note! We have now changed the CPS text into upcoming v2.2 because we completely stopped adding E values to certificates because our old methods have caused these discussions and E is not mandatory for Customers.
>
> In my opinion E value requirements in BR are much more like weak OU process than any of the strict processes. And that is how it should be because there is no sense to require company support teams to accept each of your OV certificate but the current hostmaster acceptance related to SAN domains is enough.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

0
Dimitris
8/21/2018 9:28:32 AM
I agree that this culminates to what does it mean when requirement is "veri=
fied by CA". When that is not specified anywhere and specifically not in E =
validation chapter of BR I have interpreted that also weak E verification m=
ethods are acceptable. I understand that it would be "nice" to use stronger=
 methods but the point is that is it "illegal" to use weak method when such=
 method is not prohibited.

In our old process we have accepted personal addresses because in some case=
s a single person is really the "support point" of a server. In practise pe=
rsonal address has only been accepted if the same person is also the techni=
cal or administrative contact of the application. If anybody would complain=
 or we notice in our visual check that the name or address can't be correct=
 we revoke or don't accept. In practice there hasn't been any complaints ev=
er related to our approved E values (except now in the this discussion). No=
te that all used E values have originated from authenticated customers' CSR=
..

Note! Because we want to follow "best practices" we have already stopped us=
ing these weak methods based on these discussions.
0
pekka
8/21/2018 10:18:18 AM
------=_NextPart_000_0A53_01D4392F.83548EB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The BRs indeed do not have many requirements about the validation of email
addresses, but Mozilla policy is much more proscriptive here.  See, for
example, the first two items of section 2.2.

These make it pretty clear that unverified addresses are prohibited by
Mozilla policy, and validation of email addresses is not just a "best
practice"; it's required.

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-policy-bounces@lists.mozilla.org>
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 6:18 AM
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
> 
> I agree that this culminates to what does it mean when requirement is
"verified
> by CA". When that is not specified anywhere and specifically not in E
validation
> chapter of BR I have interpreted that also weak E verification methods are
> acceptable. I understand that it would be "nice" to use stronger methods
but
> the point is that is it "illegal" to use weak method when such method is
not
> prohibited.
> 
> In our old process we have accepted personal addresses because in some
cases
> a single person is really the "support point" of a server. In practise
personal
> address has only been accepted if the same person is also the technical or
> administrative contact of the application. If anybody would complain or we
> notice in our visual check that the name or address can't be correct we
revoke
> or don't accept. In practice there hasn't been any complaints ever related
to
> our approved E values (except now in the this discussion). Note that all
used E
> values have originated from authenticated customers' CSR.
> 
> Note! Because we want to follow "best practices" we have already stopped
> using these weak methods based on these discussions.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/M8RQ_FBpnEWessS6VTb2TML0gjx1vzlJ-
> To0H9f1Upk=?d=mm6rf8hUuQt34DHH-
> 53_nlyLzE85Upq8F9coCGaDGTmCGJqbCuAdYHeE6BZrlgL64266orhG4-
> qpaAxW71xS5LPicNsPA_DXJT563uavmGor9blfsKv5oGec1ZEtL6DeN_B2af59ky
> WJgTwRpJgPyaePtW0bS56tNfBkLD37-
> _2hgrxOetTnhO0RZE_zIAMg5JQcDNT7HI1pv-
> VWy3I8yTyEv6uw4jcgBZnvM1M8tEXKyVuA9YACauy_kKPqA96LdRL15tLb65uhB
> KHNxSLMNPu3DyrV7cqoOYtj5T0WnlzQCvr8w5KvOuRlrR3p9Em4zmnyGVioHn6
> 64CTycuByUDrGAL6BB806izNaJ_mduZaFq5fgCRIz1Cyjo-
> 0WVWuWqcwLrJFX0Ro-
> 4igDlcfMXvP_f1rwhPByjdggp4xXTQ%3D%3D&u=https%3A%2F%2Flists.mozilla.
> org%2Flistinfo%2Fdev-security-policy

------=_NextPart_000_0A53_01D4392F.83548EB0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw
ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx
MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71
IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS
Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+
WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh
5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr
oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG
SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS
TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ
s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx
vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76
jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ
Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM
RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy
dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw
CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl
cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw
05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW
sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF
YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP
QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn
AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T
AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9
bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E
gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ
RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz
c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k
76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX
mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP
KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx
e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5
oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN
AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz
MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB
MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A
J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+
yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo
8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh
rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy
czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV
HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp
Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA
ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0
AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA
ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh
AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA
YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP
2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ
pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI
EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB
VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG
QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes
EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTgwODIxMTMxNTMzWjAvBgkqhkiG9w0BCQQxIgQgC1TngseoMQ7Q89lVGzsdOau3chcG
msRR0WQCY8AkVPUwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBAEIe56G0aMSbW4wtD9v4kail1wGWIwfXzD0+c0x4V4xkH9U92Zf/wAMgVI0c9ejG00AfB6lD
xUJawOJzAP/5v4LMdwu9RvcO+ie2HoZvPzrEZYD0XXXN+UOxlfcege/+7C0ewLw1rkXBEMPVkipl
qG9PBtfcGZtooiWI7SoTVYOMdfEl0OMov+OuDShnVUCh5I5203kShkqR74oFVD57PhVzv8vvYBUY
5pUd+ThifSSdpcZCEuljSpB02ge4Excm9Po8H3jL7zlzxWn5jIQYO4hcbleBNmbRQNjkhyVgFAr8
SYRUZYuIysyAfMPLaHBzQt9WnyF8/u6vpFhoXVCaXYgAAAAAAAA=

------=_NextPart_000_0A53_01D4392F.83548EB0--
0
Tim
8/21/2018 1:15:38 PM
The first item in Mozilla policy is impossible for all CAs related to E ver=
ification because there aren't any valid independent sources to check suppo=
rt email addresses. You potentially could validate only domain part of the =
email address which doesn't cover the requirement that ALL information must=
 be verified from such source. Most persons in this discussion have recomme=
nded using challenge-response method in E verification but I'm afraid it is=
 also against Mozilla requirement 2.1step1 because no independent source or=
 similar is involved.

The second item in Mozilla policy is not valid because these SSL certificat=
es are not capable in email messaging. It is clear for SMIME certificates a=
nd with them we follow it.
0
pekka
8/21/2018 1:40:49 PM
------=_NextPart_000_0A91_01D43933.C5489290
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Previous discussions on this list, which all CAs are required to follow,
have made
it clear that either challenge-response or domain validation is sufficient
to meet
Mozilla's policy for e-mail addresses.

Yes, the context was SMIME validation, but I am very troubled to hear that
instead of using the same rules for E validation, a CA would argue that it's
appropriate or allowed to do virtually no validation at all.  It's not.

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-policy-bounces@lists.mozilla.org>
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 9:41 AM
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
> 
> The first item in Mozilla policy is impossible for all CAs related to E
verification
> because there aren't any valid independent sources to check support email
> addresses. You potentially could validate only domain part of the email
address
> which doesn't cover the requirement that ALL information must be verified
> from such source. Most persons in this discussion have recommended using
> challenge-response method in E verification but I'm afraid it is also
against
> Mozilla requirement 2.1step1 because no independent source or similar is
> involved.
> 
> The second item in Mozilla policy is not valid because these SSL
certificates are
> not capable in email messaging. It is clear for SMIME certificates and
with them
> we follow it.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/_lQ2yVFZFmZcMjnytNPPhWO033O4qV_A
> d55EzA51Pnk=?d=Y3bT5wPI37DMxsvQ8o4N0HWiVOyK-
> eNjbf7Jxhf7xvbeeJ8yf2cm7BADzRYUkQBvJRPouhxTXVjeAHvJIbLkG1NtZ1dnYnq
> Y9ml3RxSoU8xz4soa15OSeMmOPKzQVmJY7ww9X4cgmfNXg_uQol0UxeXzoYO
> yGMgMGSxVEC9cnLih0UOrXrJ5LjeSUxitIBgvH5FkQI1xfXEjNw9wtpbPvdyEhaqo
> ON0bDkt0yC_Hu_UdML9zgpKAP49LuY60sd9_6Qq96a8c8-
> fyjS0hTrOnMPIXsWafHYDN9NT4eHV5nEf1efk9v28xBU02Kv-
> J_s5IwNByYW_TzPwQUEE4faBuitNYmCr_sJkSY2jMpE3xWHJxAGZWtkcKHHOm
> gv6V4X3GGPDexnyYYzEaV2tSYdUJi7zc-uno0zG9-
> CjM7SqOuA%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> security-policy

------=_NextPart_000_0A91_01D43933.C5489290
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw
ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx
MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71
IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS
Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+
WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh
5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr
oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG
SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS
TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ
s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx
vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76
jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ
Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM
RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy
dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw
CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl
cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw
05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW
sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF
YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP
QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn
AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T
AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9
bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E
gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ
RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz
c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k
76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX
mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP
KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx
e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5
oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN
AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz
MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB
MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A
J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+
yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo
8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh
rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy
czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV
HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp
Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA
ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0
AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA
ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh
AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA
YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP
2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ
pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI
EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB
VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG
QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes
EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTgwODIxMTM0NjAxWjAvBgkqhkiG9w0BCQQxIgQg7oFWVbqY1t1/yKGxgrJ3r+iFxUOl
BHFcFszF2AhUiocwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBALwOopRBAuflnB95EC0Gj1xrlfhe6BzPaA0OMon2U3zkks5LxYSwujdRoUgtjw2Y5OT7xWCr
0o7YtAhX18BBLF0Ra2I0zPE3N4xWkwyuFhQM2bcp/4dcu4jh+Jp2KtRWS/zwIzJflw9w2ANYI8uv
UdHbzaeH72rNyL6avzUxwJ/nxDOeX8zW9CMSuxZiMK46LoJvNk8T7qd5NRpf4rPsQDcdw1My7pkV
ozW6yT/CIJiixQwQ35DnIV0YbGtc/50H3bTCkMpchQJRCd0ZyNHzNIvNlk0Qeb8kcUGuIUrHbmPi
RqTL9kwkKXckAg/LSF3NarW3gfIdamnJxRTystBNgh0AAAAAAAA=

------=_NextPart_000_0A91_01D43933.C5489290--
0
Tim
8/21/2018 1:46:06 PM
The purpose of this E value and SAN-rfc822 value is completely different. T=
he former is typically an information to server users where is its support.=
 The latter for email messaging. Thus it is natural that the verification r=
equirements of those two fields are also different (like they are).=20

I completely agree that verification of SAN-rfc822 has to be challenge-resp=
onse or domain based but the same doesn't apply to this E which is only inf=
ormative field like OU.
0
pekka
8/21/2018 1:58:32 PM
------=_NextPart_000_0AB2_01D43935.B0F197E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Yeah, but unvalidated "information" is not "informative" in any useful way.

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-policy-bounces@lists.mozilla.org>
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 9:59 AM
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
> 
> The purpose of this E value and SAN-rfc822 value is completely different.
The
> former is typically an information to server users where is its support.
The
> latter for email messaging. Thus it is natural that the verification
requirements
> of those two fields are also different (like they are).
> 
> I completely agree that verification of SAN-rfc822 has to be
challenge-response
> or domain based but the same doesn't apply to this E which is only
informative
> field like OU.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/L6gW5CkSOwyu-
> 5hl92vrKoozZhevZGTi1bqkARk0lDA=?d=tcaVpOxV1GZEsht-O5I-
> U1jUfOFbghk57eRNA4QIgc3Uw4rUol-c03Y4fMcVWJF1ZerQdZi4v4h-np-
> 1dARE42nMHSf8aUFNZjD_8NbzDyxU48VdpbKSdRNuh9TCm1_xS39jm-
> iu5N39wqrGYHD09F1LIinG2AXeJODvae0i3tBZynuZyDpFRwK5fgr87sR8O6J9gzW
> vb6SiokKC-
> 2Vd7BTaTuruLtXnLBM25IHfj77EQICOI2CKxe3iYbKmYS7XsoLfUBjpvdbXQ7AwL9
> sV56X2vvD74hClclwAD85eyRj5DtN6_7eqs95arC4rNn3vVKlBuXwUv5M83ljY_sFi
> EBHNG0-8TOuURHS9h-
> L841SrtQumQ8qWSMjOCKHG2Jnn8Xr2OOLWnoY7ZKVoGhEmT7RD8NgG29ipn
> F320B_Lcw%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> security-policy

------=_NextPart_000_0AB2_01D43935.B0F197E0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw
ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx
MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71
IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS
Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+
WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh
5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr
oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG
SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS
TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ
s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx
vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76
jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ
Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM
RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy
dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw
CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl
cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw
05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW
sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF
YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP
QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn
AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T
AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9
bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E
gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ
RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz
c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k
76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX
mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP
KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx
e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5
oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN
AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz
MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB
MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A
J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+
yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo
8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh
rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy
czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV
HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp
Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA
ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0
AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA
ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh
AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA
YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP
2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ
pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI
EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB
VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG
QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes
EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTgwODIxMTM1OTQ2WjAvBgkqhkiG9w0BCQQxIgQgYFxiPhZ5FLoZdZ0cVIF2j8G4K9LL
wj6/9IX+1QF60PEwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBAAzUKbNqPKLYro1wRg0vU/orqJiWt2OC5f5XZfVzLaRdW999akpZbv6lVZQXQW2NFn1M+18+
vpuwP0IFMgNQtQuZwHzeAODsKfaQg0z7Xh/QHzXuj2uvvCEmMexahE+UxOVQlscyztRMy5uBbQxr
sfrLZ8wby+hLydgdRlMSdWn2paL6VbXGZFBWBte2/ynJ2ICQOUTtcqwQZw6fu6n6DL655mHCbwQk
f5Ey9781LIhER7wPhctqbERhGnTt6GPemIyRYLT8v2Tp9bSroaqe4KRm4b6oYxt8O7fEVJb2a6PD
BZW82Oz6LTKfu5NLMb7JcekRwei0MMfSBRiusRunmrMAAAAAAAA=

------=_NextPart_000_0AB2_01D43935.B0F197E0--
0
Tim
8/21/2018 1:59:51 PM
I believe it has been useful to our users even though it was only partially verified like OU. Now when it no more exists it certainly won't provide any help to anybody. 

0
pekka
8/21/2018 2:44:40 PM
------=_NextPart_000_0ABF_01D4393D.4DF4BCA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

There are lots of useful ways to publish unverified and potentially
inaccurate information.

Putting that information into a certificate signed by a public Certificate
Authority is
not one of them.

By the way, OUs need to be accurate as well, not just "partially verified",
so you might
want to look into that part of your processes as well.

BR 7.1.4.2: "By issuing the Certificate, the CA represents that it followed
the procedure 
set forth in its Certificate Policy and/or Certification Practice Statement
to verify that, as 
of the Certificate's issuance date, all of the Subject Information was
accurate."

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-policy-bounces@lists.mozilla.org>
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 10:45 AM
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
> 
> I believe it has been useful to our users even though it was only
partially
> verified like OU. Now when it no more exists it certainly won't provide
any help
> to anybody.
> 
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/tLUDvyC5tYQiVfqxZIo-c6Uq1a-
> jYOSGbZgRSHyUu1I=?d=zx9qYFefn2ZoXZK3hmoD2hX8Ch__jFtWDZM2CKgWQJ
> Ch5jZYL0ITP0GCk4W9UJI_8nQ6wryVSVMb4y504R9AbIRgEYDp_Umfk051kQR7s
> GVVgzxufqgL7iW3mtbBnroiKhwVEtkMa0IAxmXRTpWu9-
> pldvu8X2WSILON7AWHr-Twz3K3XJ0Ta9hXzKo2YjG4Qhxied-
> um1T97LsQ8H4mpGKC-
> zWuvaCTASohQCwcYAYMEhBqMfI9QS5AYzG3Ba5k10Kum32iQh9lrzUZP-
> 1JnjpJ8PRepHhaa7uNWbZbK_3JMKc_e6PKjA7dXMIqsa846_H9JlvO8TS4cmrHLv
> U0EkO0yv8s75TfAUqiRJlODRxOdcmNpG7-IByKbQxcsYwj1ZFmGkThjIl0AVQ_Y-
> GBp7X48byWDcHqqEkf10tsuQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%
> 2Flistinfo%2Fdev-security-policy

------=_NextPart_000_0ABF_01D4393D.4DF4BCA0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw
ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx
MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71
IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS
Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+
WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh
5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr
oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG
SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS
TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ
s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx
vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76
jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ
Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM
RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy
dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw
CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl
cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw
05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW
sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF
YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP
QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn
AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T
AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9
bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E
gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ
RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz
c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k
76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX
mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP
KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx
e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5
oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN
AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz
MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB
MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A
J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+
yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo
8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh
rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy
czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV
HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp
Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA
ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0
AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA
ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh
AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA
YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP
2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ
pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI
EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB
VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG
QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes
EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTgwODIxMTQ1NDE2WjAvBgkqhkiG9w0BCQQxIgQg1ozIse1wrZfR/HKEfNxQzEIkf0Oo
4Zbs9QSUKogR6RswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBALrh+xxHll5wsGOxqOJ23WPTwPKmXXPSpe8MT7UkJ1rGfObODMr4dmG4m2AT0GGJsTe2XxAt
+5ptIG46sR3brx/O+EIHtdUT6+GyaUkjvd8Fk9Y0j5wlDzwa1KE55q7GSvYuDSrRLDu/G2sXMZFN
uOga818bs6/e76qXV65yWu5E4b+NgHyBZxGYJ2ctibyaqWzKX4ZLNyZNEApTehvZiGMDBkkB1l6E
EzOv2osTL152xpbTpsXS7vdjLTtcc735LwybF6E2j9L76eHr6ic0Uq0JgbmVykeUX9OljPvSOvuW
UkLcpWBZOhEVqHaQyzL5Rukkds8xWqJMPGIfY6v4ZUkAAAAAAAA=

------=_NextPart_000_0ABF_01D4393D.4DF4BCA0--
0
Tim
8/21/2018 2:54:21 PM
On 21/08/2018 16:54, Tim Hollebeek wrote:
> There are lots of useful ways to publish unverified and potentially
> inaccurate information.
> 
> Putting that information into a certificate signed by a public Certificate
> Authority is
> not one of them.
> 
> By the way, OUs need to be accurate as well, not just "partially verified",
> so you might
> want to look into that part of your processes as well.

Just curious, what validation procedure would apply to legitimate OU
values like:

"HQ" or "Datacenter 3" or "Sales"

And which ones would apply to uniqueness OUs like:

"2019-Apr" indicating this is the certificate requested in April 2019,
not the otherwise identical certificates requested in February 2019 and
June 2019?


> 
> BR 7.1.4.2: "By issuing the Certificate, the CA represents that it followed
> the procedure
> set forth in its Certificate Policy and/or Certification Practice Statement
> to verify that, as
> of the Certificate's issuance date, all of the Subject Information was
> accurate."
> 
> -Tim
> 
>> -----Original Message-----
>> From: dev-security-policy <dev-security-policy-bounces@lists.mozilla.org>
> On
>> Behalf Of pekka.lahtiharju--- via dev-security-policy
>> Sent: Tuesday, August 21, 2018 10:45 AM
>> To: mozilla-dev-security-policy@lists.mozilla.org
>> Subject: Re: Telia CA - problem in E validation
>>
>> I believe it has been useful to our users even though it was only
> partially
>> verified like OU. Now when it no more exists it certainly won't provide
> any help
>> to anybody.
>>



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S�borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
0
Jakob
8/21/2018 3:31:03 PM
Also curious what validation methods should be used for OU and E when Mozilla policy 2.2.1 is...

"All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information"

....and you say that no potentially inaccurate information is allowed to put to certificates.

Is it so that the only compatible option for CA is to reject all E and almost all OU values?
0
pekka
8/23/2018 11:34:06 AM
Telia has described their plans to remediate the qualifications listed in
their latest audit reports:
https://bugzilla.mozilla.org/show_bug.cgi?id=1475115#c13

In summary:

* Telia is planning to obtain point-in-time audit reports to confirm that
the issues have been resolved. I have asked Telia to include specific
statements in their Management Assertions confirming that each
qualification has been fixed.

* One of the qualifications concerns the contents of their root
certificates, so Telia is planning to replace them but will require
significant time to go through the root inclusion process before the
non-BR-compliant roots can be removed. Until that happens, we can expect to
see this qualification on their audit reports.

* Finally, in regard to the improperly validated email address in
Subject:emailAddress, Telia stopped including this field in July, but plans
to let the existing certificates expire naturally. I would expect the
failure to revoke to be another qualification captured on Telia's next
period-of-time BR audit.

- Wayne

On Thu, Aug 23, 2018 at 4:34 AM pekka.lahtiharju--- via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> Also curious what validation methods should be used for OU and E when
> Mozilla policy 2.2.1 is...
>
> "All information that is supplied by the certificate subscriber MUST be
> verified by using an independent source of information"
>
> ...and you say that no potentially inaccurate information is allowed to
> put to certificates.
>
> Is it so that the only compatible option for CA is to reject all E and
> almost all OU values?
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
0
Wayne
9/6/2018 9:46:19 PM
Reply: