Forwarded Message
Subject: Summary of August 2018 Audit Reminder Emails
Date: Tue, 21 Aug 2018 19:00:10 + (GMT)
Mozilla: Audit Reminder
Root Certificates:
AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2333=pdf
Audit Statement Date:
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
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
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
Yeah, but unvalidated "information" is not "informative" in any useful way.
-Tim
> -Original Message-
> From: dev-security-policy
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 9:59 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
>
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).
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 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
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
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
12 matches
Mail list logo
