Telia CA - problem in E validation

[pekka.la...@teliasonera.com]

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 deviations was a statement that "Telia did not have controls to adequately verify the email address information (of SSL certificates)". Telia has always verified E values only visually and Registration officer (or certificate inspector in some cases) has to manually accept each value but only clearly incorrect values or syntactically incorrect values have been thus far rejected. 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 certificates because of this deviation because Telia won't know how they could be reasonably verified otherwise. Plan is to implement this removal in September 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 when BR text is like this "All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA." Before this discussion Telia plan is not to revoke previously enrolled 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 is one of the most common CSR generators automatically adds it to the CSR and old Telia process has accepted the values unless they are incorrect in visual verification or syntactically incorrect. Actual count and list of problematic E values will be generated in August 2018.

Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now:
Telia hasn't understand that E values should be verified using some other method than using visual check. Before this year it hasn't been on audit comments 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 2018
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

[Wayne Thayer]

Thank you for supplying this incident report. For reference, this is in
response to https://bugzilla.mozilla.org/show_bug.cgi?id=1475115

On Fri, Aug 3, 2018 at 1:55 AM pekka.lahtiharju--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 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
> deviations was a statement that "Telia did not have controls to adequately
> verify the email address information (of SSL certificates)". Telia has
> always verified E values only visually and Registration officer (or
> certificate inspector in some cases) has to manually accept each value but
> only clearly incorrect values or syntactically incorrect values have been
> thus far rejected. 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
> certificates because of this deviation because Telia won't know how they
> could be reasonably verified otherwise. Plan is to implement this removal
> in September 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 when BR text is like this "All other optional attributes, when
> present within the subject field, MUST contain information that has been
> verified by the CA." Before this discussion Telia plan is not to revoke
> previously enrolled OV certificates with visually verified E values.
>

> It is rare for a CA to include subject:emailAddress in a serverAuth
certificate. I suspect that sending a random value to the email address and
receiving a response (BR 3.2.2.4.2) is the most common way that CAs verify
email addresses.

Summary and details of problematic certificates:
> Lots of existing Telia OV certificates have E value because Openssl which
> is one of the most common CSR generators automatically adds it to the CSR
> and old Telia process has accepted the values unless they are incorrect in
> visual verification or syntactically incorrect. Actual count and list of
> problematic E values will be generated in August 2018.
>
> Explanation about how and why the mistakes were made or bugs introduced,
> and how they avoided detection until now:
> Telia hasn't understand that E values should be verified using some other
> method than using visual check. Before this year it hasn't been on audit
> comments 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
> 2018
> 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
>

> Crt.sh lists over 3,400 Telia certificates containing a
Subject:emailAddress. BR 4.9.1.1(9) requires revocation within 24 hours.
Failure to revoke is a BR violation, even if this issues does not "cause a
security problem".

[Ryan Sleevi]

On Fri, Aug 3, 2018 at 3:53 AM pekka.lahtiharju--- via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> 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
> deviations was a statement that "Telia did not have controls to adequately
> verify the email address information (of SSL certificates)". Telia has
> always verified E values only visually and Registration officer (or
> certificate inspector in some cases) has to manually accept each value but
> only clearly incorrect values or syntactically incorrect values have been
> thus far rejected. 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
> certificates because of this deviation because Telia won't know how they
> could be reasonably verified otherwise. Plan is to implement this removal
> in September 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 when BR text is like this "All other optional attributes, when
> present within the subject field, MUST contain information that has been
> verified by the CA." Before this discussion Telia plan is not to revoke
> previously enrolled 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
> is one of the most common CSR generators automatically adds it to the CSR
> and old Telia process has accepted the values unless they are incorrect in
> visual verification or syntactically incorrect. Actual count and list of
> problematic E values will be generated in August 2018.

>From a system design perspective, this is deeply concerning. It sounds as
if the old Telia processes may have copied any number of bits over from the
CSR, without validation that they were fit for the certificate profile or
appropriate for inclusion.

Has Telia re-examined all of its certificates issued under the old system,
to ensure that all certificates conform with the CP/CPS profiles (such as
including other subject attributes requested by customers, beyond
emailAddress, not in accordance with its policies)? Has it maintained
sufficient documentation to confidentially demonstrate that the fields that
are included have been validated accordingly?

Perhaps most concerning is it sounds as if the system used the CSR value
for fields - which might allow visually confusing characters to be
introduced or other subtleties that CAs have encountered (such as embedded
NULs), leading to misleading or inaccurate information. How do Telia’s new
processes account for this? Greater transparency around the “new” system
(since the distinction is being made between old and new), how information
is entered, and how it is validated seem useful contributions to the
discussion of remediation and mitigation.

>
> Explanation about how and why the mistakes were made or bugs introduced,
> and how they avoided detection until now:
> Telia hasn't understand that E values should be verified using some other
> method than using visual check. Before this year it hasn't been on audit
> comments 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
> 2018
> 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
>
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[pekka.la...@teliasonera.com]

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.

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 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?

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.

[Ryan Sleevi]

On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
<dev-secur...@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?

[pekka.la...@teliasonera.com]

> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
> <dev-secur...@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)
sup...@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.

[pekka.la...@teliasonera.com]

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-policy
> <dev-secur...@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 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 looks 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)

casu...@telia.fi – Accepted by all Telia E verifications

If Telia wouldn’t use any E verification all above values were accepted. 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 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 postpone certificate application acceptance is problematic and very few methods are thus suitable in practice.

[pekka.la...@teliasonera.com]

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-policy
> <dev-secur...@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've verified 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 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)

sup...@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, 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 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.

[pekka.la...@teliasonera.com]

> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
> <dev-secur...@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)
sup...@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.

[pekka.la...@teliasonera.com]

> > 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."

[Jakob Bohm]

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

[pekka.la...@teliasonera.com]

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.

[Ryan Sleevi]

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?

[Jakob Bohm]

On 20/08/2018 10:06, pekka.la...@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.

[pekka.la...@teliasonera.com]

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.

[Dimitris Zacharopoulos]

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.la...@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.

[pekka.la...@teliasonera.com]

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.

[Tim Hollebeek]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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

[pekka.la...@teliasonera.com]

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.

[Tim Hollebeek]

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-...@lists.mozilla.org>
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 9:41 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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

[pekka.la...@teliasonera.com]

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.

[Tim Hollebeek]

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

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 9:59 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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

[pekka.la...@teliasonera.com]

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.

[Tim Hollebeek]

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-...@lists.mozilla.org>
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 10:45 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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

[Jakob Bohm]

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-...@lists.mozilla.org>
> On
>> Behalf Of pekka.lahtiharju--- via dev-security-policy
>> Sent: Tuesday, August 21, 2018 10:45 AM
>> To: mozilla-dev-s...@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.
>>

[pekka.la...@teliasonera.com]

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?

[Wayne Thayer]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Wayne Thayer]

Telia has supplied the point-in-time audit reports required to verify
remediation of the audit issues that were described in this thread and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1475115

Links to the PiT reports:

https://support.trust.telia.com/download/CA/Telia-WebTrust-for-CA-Report-2018-10-31.pdf
https://support.trust.telia.com/download/CA/Telia-SSL-Baseline-Requirements-Report-2018-10-31.pdf

Other than the qualification noted below for their existing root
certificate, the PiT reports are clean, so I have resolved the incident bug.

- Wayne