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

8 Replies
28 Views

Similar Articles

[PageSpeed] 7

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
Reply: