Re: Audit Reminder Email Summary
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&file=pdf Audit Statement Date: 2017-08-09 CA Comments: null Mozilla: Audit Reminder Root Certificates: Certinomis - Root CA Standard Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169 Audit Statement Date: 2017-07-24 BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169 BR Audit Statement Date: 2017-07-24 CA Comments: null Mozilla: Audit Reminder Root Certificates: E-Tugra Certification Authority Standard Audit: https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf Audit Statement Date: 2017-09-09 BR Audit: https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf BR Audit Statement Date: 2017-09-09 EV Audit: https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf EV Audit Statement Date: 2017-09-09 CA Comments: null Mozilla: Audit Reminder Root Certificates: Go Daddy Class 2 CA Go Daddy Root Certificate Authority - G2 Starfield Class 2 CA Starfield Root Certificate Authority - G2 Standard Audit: https://cert.webtrust.org/SealFile?seal=2332&file=pdf Audit Statement Date: 2017-08-31 BR Audit: https://cert.webtrust.org/SealFile?seal=2332&file=pdf BR Audit Statement Date: 2017-08-31 EV Audit: https://cert.webtrust.org/SealFile?seal=2332&file=pdf EV Audit Statement Date: 2017-08-31 CA Comments: null Mozilla: Audit Reminder Root Certificates: ACCVRAIZ1 Standard Audit: https://cert.webtrust.org/SealFile?seal=2299&file=pdf Audit Statement Date: 2017-07-28 BR Audit: https://cert.webtrust.org/SealFile?seal=2300&file=pdf BR Audit Statement Date: 2017-07-28 CA Comments: Per CA request, Root CA Generalitat Valenciana will be removed via https://bugzilla.mozilla.org/show_bug.cgi?id=1272158 Mozilla: Audit Reminder Root Certificates: IdenTrust Commercial Root CA 1** IdenTrust Public Sector Root CA 1** DST Root CA X3** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://cert.webtrust.org/SealFile?seal=2331&file=pdf Audit Statement Date: 2017-08-31 BR Audit: https://cert.webtrust.org/SealFile?seal=2334&file=pdf BR Audit Statement Date: 2017-09-18 CA Comments: null Mozilla: Audit Reminder Root Certificates: Izenpe.com Standard Audit: http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf Audit Statement Date: 2017-07-25 BR Audit: http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf BR Audit Statement Date: 2017-07-25 EV Audit: http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf EV Audit Statement Date: 2017-07-25 CA Comments: null Mozilla: Audit Reminder Root Certificates: OpenTrust Root CA G1 OpenTrust Root CA G2 Certplus Root CA G1 Class 2 Primary CA OpenTrust Root CA G3 Certplus Root CA G2 Standard Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590 Audit Statement Date: 2017-07-24 BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590 BR Audit Statement Date: 2017-07-24 CA Comments: null Mozilla: Audit Reminder Root Certificates: SECOM Trust.net - Security Communication RootCA1 Security Communication RootCA2 Standard Audit: https://cert.webtrust.org/SealFile?seal=2321&file=pdf Audit Statement Date: 2017-08-31 BR Audit: https://cert.webtrust.org/SealFile?seal=2323&file=pdf BR Audit Statement Date: 2017-08-31 EV Audit: https://cert.webtrust.org/SealFile?seal=2322&file=pdf EV Audit Statement Date: 2017-08-31 CA Comments: null Mozilla: Overdue Audit Statements Root Certificates: SwissSign Platinum CA - G2** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552 Audit Statement Date: 2017-03-30 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552 BR Audit Statement Date: 2017-03-30 CA Comments: null Mozilla: Audit Reminder Root Certificates: Visa eCommerce Root Standard Audit: http://enroll.visaca.com/WTCA%20eComm.pdf Audit Statement Date: 2017-07-26 BR Audit: http://enroll.visaca.com/WTBR%20eComm.pdf BR Audit Statement Date: 2017-07-26 CA Comments: null Mozilla: Audit Reminder Root Certificates: SSL.com EV Root Certification Authority ECC SSL.com Root Certification Authority ECC SSL.com Root Certification Authority RSA SSL.com EV Root Certification Authority RSA R2 Standard Audit: https://www.ssl.com/app/uploads/2017/07/SSL-COM-WTCA-Indp-Accountant-Report-and-Mgmt-Assertion-FINAL-2017.pd
Re: Telia CA - problem in E validation
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 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 - problem in E validation I believe it has been useful to our users even though it was only partially verified like OU. Now when it no more exists it certainly won't provide any help to anybody. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Telia CA - problem in E validation
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 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 - problem in E validation > > I believe it has been useful to our users even though it was only partially > verified like OU. Now when it no more exists it certainly won't provide any help > to anybody. > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/tLUDvyC5tYQiVfqxZIo-c6Uq1a- > jYOSGbZgRSHyUu1I=?d=zx9qYFefn2ZoXZK3hmoD2hX8Ch__jFtWDZM2CKgWQJ > Ch5jZYL0ITP0GCk4W9UJI_8nQ6wryVSVMb4y504R9AbIRgEYDp_Umfk051kQR7s > GVVgzxufqgL7iW3mtbBnroiKhwVEtkMa0IAxmXRTpWu9- > pldvu8X2WSILON7AWHr-Twz3K3XJ0Ta9hXzKo2YjG4Qhxied- > um1T97LsQ8H4mpGKC- > zWuvaCTASohQCwcYAYMEhBqMfI9QS5AYzG3Ba5k10Kum32iQh9lrzUZP- > 1JnjpJ8PRepHhaa7uNWbZbK_3JMKc_e6PKjA7dXMIqsa846_H9JlvO8TS4cmrHLv > U0EkO0yv8s75TfAUqiRJlODRxOdcmNpG7-IByKbQxcsYwj1ZFmGkThjIl0AVQ_Y- > GBp7X48byWDcHqqEkf10tsuQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org% > 2Flistinfo%2Fdev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Telia CA - problem in E validation
I believe it has been useful to our users even though it was only partially verified like OU. Now when it no more exists it certainly won't provide any help to anybody. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Telia CA - problem in E validation
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 > Subject: Re: Telia CA - problem in E validation > > The purpose of this E value and SAN-rfc822 value is completely different. The > former is typically an information to server users where is its support. The > latter for email messaging. Thus it is natural that the verification requirements > of those two fields are also different (like they are). > > I completely agree that verification of SAN-rfc822 has to be challenge-response > or domain based but the same doesn't apply to this E which is only informative > field like OU. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/L6gW5CkSOwyu- > 5hl92vrKoozZhevZGTi1bqkARk0lDA=?d=tcaVpOxV1GZEsht-O5I- > U1jUfOFbghk57eRNA4QIgc3Uw4rUol-c03Y4fMcVWJF1ZerQdZi4v4h-np- > 1dARE42nMHSf8aUFNZjD_8NbzDyxU48VdpbKSdRNuh9TCm1_xS39jm- > iu5N39wqrGYHD09F1LIinG2AXeJODvae0i3tBZynuZyDpFRwK5fgr87sR8O6J9gzW > vb6SiokKC- > 2Vd7BTaTuruLtXnLBM25IHfj77EQICOI2CKxe3iYbKmYS7XsoLfUBjpvdbXQ7AwL9 > sV56X2vvD74hClclwAD85eyRj5DtN6_7eqs95arC4rNn3vVKlBuXwUv5M83ljY_sFi > EBHNG0-8TOuURHS9h- > L841SrtQumQ8qWSMjOCKHG2Jnn8Xr2OOLWnoY7ZKVoGhEmT7RD8NgG29ipn > F320B_Lcw%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev- > security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Telia CA - problem in E validation
The purpose of this E value and SAN-rfc822 value is completely different. The former is typically an information to server users where is its support. The latter for email messaging. Thus it is natural that the verification requirements of those two fields are also different (like they are). I completely agree that verification of SAN-rfc822 has to be challenge-response or domain based but the same doesn't apply to this E which is only informative field like OU. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Telia CA - problem in E validation
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 On > Behalf Of pekka.lahtiharju--- via dev-security-policy > Sent: Tuesday, August 21, 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 > addresses. You potentially could validate only domain part of the email address > which doesn't cover the requirement that ALL information must be verified > from such source. Most persons in this discussion have recommended using > challenge-response method in E verification but I'm afraid it is also against > Mozilla requirement 2.1step1 because no independent source or similar is > involved. > > The second item in Mozilla policy is not valid because these SSL certificates are > not capable in email messaging. It is clear for SMIME certificates and with them > we follow it. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/_lQ2yVFZFmZcMjnytNPPhWO033O4qV_A > d55EzA51Pnk=?d=Y3bT5wPI37DMxsvQ8o4N0HWiVOyK- > eNjbf7Jxhf7xvbeeJ8yf2cm7BADzRYUkQBvJRPouhxTXVjeAHvJIbLkG1NtZ1dnYnq > Y9ml3RxSoU8xz4soa15OSeMmOPKzQVmJY7ww9X4cgmfNXg_uQol0UxeXzoYO > yGMgMGSxVEC9cnLih0UOrXrJ5LjeSUxitIBgvH5FkQI1xfXEjNw9wtpbPvdyEhaqo > ON0bDkt0yC_Hu_UdML9zgpKAP49LuY60sd9_6Qq96a8c8- > fyjS0hTrOnMPIXsWafHYDN9NT4eHV5nEf1efk9v28xBU02Kv- > J_s5IwNByYW_TzPwQUEE4faBuitNYmCr_sJkSY2jMpE3xWHJxAGZWtkcKHHOm > gv6V4X3GGPDexnyYYzEaV2tSYdUJi7zc-uno0zG9- > CjM7SqOuA%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev- > security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Telia CA - problem in E validation
The first item in Mozilla policy is impossible for all CAs related to E verification because there aren't any valid independent sources to check support email addresses. You potentially could validate only domain part of the email address which doesn't cover the requirement that ALL information must be verified from such source. Most persons in this discussion have recommended using challenge-response method in E verification but I'm afraid it is also against Mozilla requirement 2.1step1 because no independent source or similar is involved. The second item in Mozilla policy is not valid because these SSL certificates are not capable in email messaging. It is clear for SMIME certificates and with them we follow it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Telia CA - problem in E validation
The BRs indeed do not have many requirements about the validation of email addresses, but Mozilla policy is much more proscriptive here. See, for example, the first two items of section 2.2. These make it pretty clear that unverified addresses are prohibited by Mozilla policy, and validation of email addresses is not just a "best practice"; it's required. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of pekka.lahtiharju--- via dev-security-policy > Sent: Tuesday, August 21, 2018 6:18 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Telia CA - problem in E validation > > I agree that this culminates to what does it mean when requirement is "verified > by CA". When that is not specified anywhere and specifically not in E validation > chapter of BR I have interpreted that also weak E verification methods are > acceptable. I understand that it would be "nice" to use stronger methods but > the point is that is it "illegal" to use weak method when such method is not > prohibited. > > In our old process we have accepted personal addresses because in some cases > a single person is really the "support point" of a server. In practise personal > address has only been accepted if the same person is also the technical or > administrative contact of the application. If anybody would complain or we > notice in our visual check that the name or address can't be correct we revoke > or don't accept. In practice there hasn't been any complaints ever related to > our approved E values (except now in the this discussion). Note that all used E > values have originated from authenticated customers' CSR. > > Note! Because we want to follow "best practices" we have already stopped > using these weak methods based on these discussions. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/M8RQ_FBpnEWessS6VTb2TML0gjx1vzlJ- > To0H9f1Upk=?d=mm6rf8hUuQt34DHH- > 53_nlyLzE85Upq8F9coCGaDGTmCGJqbCuAdYHeE6BZrlgL64266orhG4- > qpaAxW71xS5LPicNsPA_DXJT563uavmGor9blfsKv5oGec1ZEtL6DeN_B2af59ky > WJgTwRpJgPyaePtW0bS56tNfBkLD37- > _2hgrxOetTnhO0RZE_zIAMg5JQcDNT7HI1pv- > VWy3I8yTyEv6uw4jcgBZnvM1M8tEXKyVuA9YACauy_kKPqA96LdRL15tLb65uhB > KHNxSLMNPu3DyrV7cqoOYtj5T0WnlzQCvr8w5KvOuRlrR3p9Em4zmnyGVioHn6 > 64CTycuByUDrGAL6BB806izNaJ_mduZaFq5fgCRIz1Cyjo- > 0WVWuWqcwLrJFX0Ro- > 4igDlcfMXvP_f1rwhPByjdggp4xXTQ%3D%3D&u=https%3A%2F%2Flists.mozilla. > org%2Flistinfo%2Fdev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Telia CA - problem in E validation
I agree that this culminates to what does it mean when requirement is "verified by CA". When that is not specified anywhere and specifically not in E validation chapter of BR I have interpreted that also weak E verification methods are acceptable. I understand that it would be "nice" to use stronger methods but the point is that is it "illegal" to use weak method when such method is not prohibited. In our old process we have accepted personal addresses because in some cases a single person is really the "support point" of a server. In practise personal address has only been accepted if the same person is also the technical or administrative contact of the application. If anybody would complain or we notice in our visual check that the name or address can't be correct we revoke or don't accept. In practice there hasn't been any complaints ever related to our approved E values (except now in the this discussion). Note that all used E values have originated from authenticated customers' CSR. Note! Because we want to follow "best practices" we have already stopped using these weak methods based on these discussions. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Telia CA - problem in E validation
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.lahtiha...@teliasonera.com", which seems like a legitimate email address, wouldn't you approve it? If not, why not? Dimitris. On 21/8/2018 11:53 πμ, pekka.lahtiharju--- via dev-security-policy wrote: In my opinion we follow BR. Here is why: I think that the first chapter of 7.1.4.2 it says that "...CA represents it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify...". That is exactly what we do because we have explained in our CPS how E is verified (check below). Perhaps the process description in CPS could be better but anyway the descriptions are there including the fact that email (domain) ownership hasn't been always verified. More detailed E process description has been in this discussion. Then BR 7.1.4.2.j specifies how E should be verified for SSL certificates: "All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable." In our opinion we follow also completely that chapter because we do two kind of verifications to E values and also we prevent meta data values like required. Note that it is not prohibited in BR text to use our methods. I still can't understand what is the exact BR detail that hasn't been followed by us? We haven't verified everything (specifically E) perfectly but we have followed our CPS and our E process has been written to be compatible to current BR 7.1.4.2.j. Our current CPS v2.1 has E verification documentation mostly in chapter "3.2.4 Non-verified Subscriber Information" and partly in 3.2.2. Our CPS is here https://repository.trust.teliasonera.com/Telia_Server_Certificate_CPS_v2.1.pdf. Relevant parts of it are copied below: --- 3.2.2: Other subject values like OU or E are verified each time separately. 3.2.4: The Registration Officer is obliged to always review all subject information and initiate additional checking routines if there are any unclear Subject values ...Domain name ownership of domains in email addresses may belong to another company than the applicant e.g. to some service provider Note! We have now changed the CPS text into upcoming v2.2 because we completely stopped adding E values to certificates because our old methods have caused these discussions and E is not mandatory for Customers. In my opinion E value requirements in BR are much more like weak OU process than any of the strict processes. And that is how it should be because there is no sense to require company support teams to accept each of your OV certificate but the current hostmaster acceptance related to SAN domains is enough. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Telia CA - problem in E validation
In my opinion we follow BR. Here is why: I think that the first chapter of 7.1.4.2 it says that "...CA represents it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify...". That is exactly what we do because we have explained in our CPS how E is verified (check below). Perhaps the process description in CPS could be better but anyway the descriptions are there including the fact that email (domain) ownership hasn't been always verified. More detailed E process description has been in this discussion. Then BR 7.1.4.2.j specifies how E should be verified for SSL certificates: "All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable." In our opinion we follow also completely that chapter because we do two kind of verifications to E values and also we prevent meta data values like required. Note that it is not prohibited in BR text to use our methods. I still can't understand what is the exact BR detail that hasn't been followed by us? We haven't verified everything (specifically E) perfectly but we have followed our CPS and our E process has been written to be compatible to current BR 7.1.4.2.j. Our current CPS v2.1 has E verification documentation mostly in chapter "3.2.4 Non-verified Subscriber Information" and partly in 3.2.2. Our CPS is here https://repository.trust.teliasonera.com/Telia_Server_Certificate_CPS_v2.1.pdf. Relevant parts of it are copied below: --- 3.2.2: Other subject values like OU or E are verified each time separately. 3.2.4: The Registration Officer is obliged to always review all subject information and initiate additional checking routines if there are any unclear Subject values ...Domain name ownership of domains in email addresses may belong to another company than the applicant e.g. to some service provider Note! We have now changed the CPS text into upcoming v2.2 because we completely stopped adding E values to certificates because our old methods have caused these discussions and E is not mandatory for Customers. In my opinion E value requirements in BR are much more like weak OU process than any of the strict processes. And that is how it should be because there is no sense to require company support teams to accept each of your OV certificate but the current hostmaster acceptance related to SAN domains is enough. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
