Re: [FORGED] Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar
For EV certificate being useful in email, email client software should give a special EV treatment to such certificate. I am not aware of any email client software that support any special EV treatment at all. Do you have more information to share with us? -- Man Ho On 13-Aug-19 5:12 PM, Kurt Roeckx via dev-security-policy wrote: > But EV is still useful for things like code signing and email. And I > would argue that EV should be the only option for such certificates. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Unretrievable CPS documents listed in CCADB
I could be wrong, but some browsers (IE/Chrome) seems to cache downloaded PDF file and display the cache file if the filename is the same. If it's true, end user may be actually reading an outdated PDF file. - Man Ho On 04-May-19 3:18 AM, Wayne Thayer via dev-security-policy wrote: > A relatively simple solution to this problem is to create a "permanent > link" to the current version of these docs (e.g. > https://digicert.com/repository/current_cp.pdf), then modify or redirect > the document that the link returns each time the document is updated as > part of the publishing process. Under this scheme, the CA should never need > to worry about updating CCADB. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Arabtec Holding public key? [Weird Digicert issued cert]
I don't think that it's trivial for less-skilled user to obtain the CSR of "DigiCert Global Root G2" certificate and posting it in the request of another certificate, right? On 15-Apr-19 6:57 PM, Jakob Bohm via dev-security-policy wrote: > Thanks for the explanation. > > Is it possible that a significant percentage of less-skilled users > simply pasted in the wrong certificates by mistake, then wondered why > their new certificates newer worked? > > Pasting in the wrong certificate from an installed certificate chain or > semi-related support page doesn't seem an unlikely user error with that > design. > > On 12/04/2019 18:56, Jeremy Rowley wrote: >> I don't mind filling in details. >> >> We have a system that permits creation of certificates without a CSR >> that works by extracting the key from an existing cert, validating >> the domain/org information, and creating a new certificate based on >> the contents of the old certificate. The system was supposed to do a >> handshake with a server hosting the existing certificate as a form of >> checking control over the private key, but that was never >> implemented, slated for a phase 2 that never came. We've since >> disabled that system, although we didn't file any incident report >> (for the reasons discussed so far). >> >> -Original Message- >> From: dev-security-policy >> On Behalf Of Wayne >> Thayer via dev-security-policy >> Sent: Friday, April 12, 2019 10:39 AM >> To: Jakob Bohm >> Cc: mozilla-dev-security-policy >> >> Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert] >> >> It's not clear that there is anything for DigiCert to respond to. Are >> we asserting that the existence of this Arabtec certificate is proof >> that DigiCert violated section 3.2.1 of their CPS? >> >> - Wayne >> >> On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> On 11/04/2019 04:47, Santhan Raj wrote: On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: > On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: >> (Resending after I typo'd the ML address) >> >> At the risk of further embarrassing myself in the same week, while >> working further on mimicking Firefox trust decisions I found this >> pre-certificate for Arabtec Holding PJSC: >> >> https://crt.sh/?id=926433948 >> >> Now there's nothing especially strange about this certificate, >> except that its RSA public key is shared with several other >> certificates >> >> >>> https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2d >>> ab76254f97fb36b82fc26 >> >> ... such as the DigiCert Global Root G2: >> >> https://crt.sh/?caid=5885 >> >> >> I would like to understand what happened here. Maybe I have once >> again made a terrible mistake, but if not surely this means either >> that the Issuing authority was fooled into issuing for a key the >> subscriber doesn't actually have or worse, this Arabtec Holding >> outfit has the private keys for DigiCert's Global Root G2 >> >> Nick. > > AFAIK there's no requirement in the BRs or Mozilla Root Policy for > CAs >>> to actually verify that the Applicant actually is in possession of the >>> corresponding private key for public keys included in CSRs (i.e., >>> check the signature on the CSR), so the most likely explanation is >>> that the CA in question did not check the signature on the >>> Applicant-submitted CSR and summarily embedded the supplied public key >>> in the certificate (assuming Digicert's CA infrastructure wasn't >>> compromised, but I think that's highly unlikely). > > A very similar situation was brought up on the list before, but > with >>> WoSign as the issuing CA: >>> https://groups.google.com/d/msg/mozilla.dev.security.policy/zECd9J3KBW >>> 8/OlK44lmGCAAJ > While not a BR requirement, the CA's CPS does stipulate validating >>> possession of private key in section 3.2.1 (looking at the change >>> history, it appears this stipulation existed during the cert >>> issuance). So something else must have happened here. Except for the Arabtec cert, the other certs looks like cross-sign for >>> the Digicert root. >>> >>> Why still no response from Digicert? Has this been reported to them >>> directly? >>> > > > Enjoy > > Jakob ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Hongkong Post Root CA 3
We have applied the changes in the current CPS, please see https://www.ecert.gov.hk/product/cps/ecert/img/server_cps_en4.pdf So, the "Pre-production" CPS will be advanced to version 5, that will replace the current CPS after Mozilla community discussion. If any member has other comments, you're welcome to bring it out. :) On 17-Jan-19 10:25 AM, Man Ho via dev-security-policy wrote: Thanks for all the comments. I'm preparing now to apply the relevant changes from the "Pre-production" CPS in the current CPS to clarify these concerns. Specifically, 1. correct the description of revocation process to fix the suspension and revocation issue. 2. make a statement in PREAMBLE that "...HKPost to appoint Registration Authorities (RAs) as its agents to carry out certain of the functions of HKPost as a Recognized CA as set out in this CPS, except the functions of domain name validation." 3. modify section 4.9.1 to include all revocation reasons required by BR 4.9.1.1 Please note that this update to the current CPS will advance the version of current CPS from version 3 to version 4. So, the "Pre-production" CPS will be version 5, replacing the current CPS. If any member has other comments, you're welcome to bring it out. On 16-Jan-19 5:30 AM, Wayne Thayer via dev-security-policy wrote: I think you and David are also suggesting that the CPS for existing roots must be updated to fix the suspension and revocation issues listed under "bad", and to clarify the external RA concern listed under "meh". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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: Request to Include Hongkong Post Root CA 3
I've just fill in the incident report [1], https://bugzilla.mozilla.org/show_bug.cgi?id=1520299 On 16-Jan-19 5:30 AM, Wayne Thayer via dev-security-policy wrote: There were no unresolved incidents, but I just created one to document the misissued certificates that were revoked in August 2018 [1]. I agree that this should be resolved prior to approval. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Hongkong Post Root CA 3
Thanks for all the comments. I'm preparing now to apply the relevant changes from the "Pre-production" CPS in the current CPS to clarify these concerns. Specifically, 1. correct the description of revocation process to fix the suspension and revocation issue. 2. make a statement in PREAMBLE that "...HKPost to appoint Registration Authorities (RAs) as its agents to carry out certain of the functions of HKPost as a Recognized CA as set out in this CPS, except the functions of domain name validation." 3. modify section 4.9.1 to include all revocation reasons required by BR 4.9.1.1 Please note that this update to the current CPS will advance the version of current CPS from version 3 to version 4. So, the "Pre-production" CPS will be version 5, replacing the current CPS. If any member has other comments, you're welcome to bring it out. On 16-Jan-19 5:30 AM, Wayne Thayer via dev-security-policy wrote: > I think you and David are also suggesting that the CPS for existing roots > must be updated to fix the suspension and revocation issues listed under > "bad", and to clarify the external RA concern listed under "meh". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Hongkong Post Root CA 3
On 15-Jan-19 12:31 PM, Ian Carroll via dev-security-policy wrote: > from looking at [3] I think it should be a > very negative mark against a CA to have to OneCRL one of their > intermediates. [3] was reported and discussed three years ago. When I look at it positively today, it does remind me that it's one of the reasons for our decision to separate root CAs for SSL certificates and non-SSL certificates. As far as I know, browsers and the web PKI community now encourage or even require the separation of CAs for different usage of certificate, e.g. time stamping, code signing, S/MIME, and SSL certificates. So, if there is a web PKI standard, we are actually glad to follow. --Man Ho ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Communication: Underscores in dNSNames
When the ballot said "... would result in a valid domain label", does it
mean that "... would result in a valid domain name of the applicant,
that has passed the same level of domain authorization (DV, OV, EV) check?
Secondly, is it necessary for CAs to state their practice of handling
underscore domain name in CPS?
- Man Ho
On 11/13/2018 7:18 AM, Wayne Thayer via dev-security-policy wrote:
> As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> creating a sunset period for TLS certificates containing an underscore
> ("_") character in the SAN. This practice was widespread until a year ago
> when it was pointed out that underscore characters are not permitted in
> dNSName name forms, and ballot 202 was proposed to create an exception to
> RFC 5280 that would allow the practice to continue. When that ballot
> failed, some CAs stopped allowing underscore characters in SANs and others
> continued. Ballot SC12 is intended to resolve this inconsistency and
> provide clear guidance to auditors.
>
> The sunset period defined by ballot SC12 is very short. Today Mozilla sent
> an email to all CAs in our program informing them of this change and asking
> them to take any steps necessary to comply [2].
>
> - Wayne
>
> [1]
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> [2]
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
> ___
> 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
