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:
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
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
8 10:45 AM
To: mozilla-dev-security-pol...@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.
ect Information was
accurate."
-Tim
> -Original Message-
> From: dev-security-policy
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 10:45 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Telia CA -
I believe it has been useful to our users even though it was only partially
verified like OU. Now when it no more exists it certainly won't provide any
help to anybody.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
v-security-pol...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
>
> The purpose of this E value and SAN-rfc822 value is completely different.
The
> former is typically an information to server users where is its support.
The
> latter for email messaging. Thu
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).
2018 9:41 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
>
> The first item in Mozilla policy is impossible for all CAs related to E
verification
> because there aren't any valid independent sources to check support email
> ad
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
.org
> Subject: Re: Telia CA - problem in E validation
>
> I agree that this culminates to what does it mean when requirement is
"verified
> by CA". When that is not specified anywhere and specifically not in E
validation
> chapter of BR I have interpreted that also weak E v
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
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
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
On 20/08/2018 10:06, pekka.lahtiha...@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
On Mon, Aug 20, 2018 at 4:06 AM, pekka.lahtiharju--- via
dev-security-policy 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
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
On 10/08/2018 13:02, pekka.lahtiha...@teliasonera.com wrote:
On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
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.
> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
> 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
> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
> 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
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
> 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
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
> 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
> On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
> 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
On Mon, Aug 6, 2018 at 3:28 AM, pekka.lahtiharju--- via dev-security-policy
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
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
On Fri, Aug 3, 2018 at 3:53 AM pekka.lahtiharju--- via dev-security-policy <
dev-security-policy@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
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-security-policy@lists.mozilla.org> wrote:
> Incident report:
>
> PROBLEM IN
27 matches
Mail list logo
