Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
Matt, Our investigation reopened at March 9, 9:36 AM based on the information you provided in this forum. We were able to research and run appropriate testing which led to evidence of key compromise being determined March 9, 10:24 AM. We continued our diligence in accordance with the Baseline Requirements and revocation completed March 10, 10:24 AM. Joanna Fox ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
Matt, Thank you for sharing your experience with our problem reporting mechanism on this forum. It is due to this that we were able to get to the root of the issue. Here is some detail into what we saw. Yesterday, we launched an investigation which included various members of the team researching this issue. We took this investigation as far as we could with the information we had and concluded that the CSR provided, as we read it, was malformed. We ran this CSR through various tools but were unable to successfully confirm validity. This morning, based on the statements in this forum, we discovered that our email system had misinterpreted the CSR formatting due to it being pasted in the body of the email. When we fix Base64 encoding, the CSR verifies. Upon this discovery we have initiated revocation to occur within the guidelines of 24 hours from obtaining evidence that the private key was compromised. We take key compromises very seriously and recognize the importance to the industry and health of the ecosystem. Lastly, we also noticed that the email you received was malformed, missing some of the required content for the OpenSSL command. This event has led to a review of our email system to learn how we can avoid malformed encoding issues in the future. Thank you, Joanna Fox GoDaddy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Underscore Revocation Disclosure
I agree on the surface this bug appears to be the same, but the root cause is a different. The issue for bug 1462844 was a specific status not counting as active when it was. To mitigate this issue, we updated the query to include the missing status. However, we are in the process of simplifying the data structures to simplify these types of queries. For the underscore certificates, these were non-active, not even considered as provisioned since they were not delivered to a customer and not publicly used for any encryption. These certificates were effectively abandoned by our system. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
GoDaddy Underscore Revocation Disclosure
GoDaddy received a certificate problem report on 1/29/2019 for 2 unrevoked unexpired certificates have underscores in the DNS name that did not meet the January 15th deadline for revocation. The certificates reported are as follows: https://crt.sh/?opt=zlint=626981823 https://crt.sh/?opt=zlint=637047181 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. Certificate Problem Reporting via email address supplied in CP/CPS on Tuesday, January 29, 2019 11:18:42 AM 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 1/29/2019 11:18:42 AM AZ time Problem Report received by GoDaddy 1/29/2019 3:55 PM AZ time Problem report was viewed by an agent and escalated appropriately. 1/29/2019 to 1/30/2019 Researched as to why these certificates were not caught in the initial data set for underscore revocation. 1/30/2019 Identified root cause as order of an operation problem where certificates could be CT logged but never be delivered to the certificate requester. 1/30/2019 23:36:32 UTC and 1/30/2019 23:35:55 UTC Certificates that were reported are revoked. 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. We have prevented new certificates with underscores from being provisioned since November 8, 2018. 4. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. https://crt.sh/?opt=zlint=626981823 https://crt.sh/?opt=zlint=637047181 5. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Our initial effort to bring underscore certificates into compliance was dependent upon an ‘active’ flag in our database. In rare cases, due to an order of operation problem, non-active certificates were being logged to CT. These non-active certificates were fully vetted meeting the BR standards but failed to be delivered to the certificate requester due to a software defect. 6. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. We have prevented new certificates with underscores from being provisioned since November 8, 2018. These non-active certificates were revoked and we are taking steps to prevent non-active certificates from being logged to CT within the next 2 weeks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
Questions about blank sections, thinking of a potential future requirement. Sections such as 1.INTRODUCTION would remain blank as they are more titles than components, correct? If no sections are allowed to be blank does this include both levels of components such as 1.4 and 1.4.1? Also, what is the opinion on adding sections to the CP/CPS that are not included in the RFC? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
On Thursday, October 18, 2018 at 5:47:14 PM UTC-7, Jakob Bohm wrote: > On 15/10/2018 20:01, Kathleen Wilson wrote: > > I have added the following section to the Required Practices wiki page: > > > > https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS > > > > I will continue to appreciate feedback on this update. > > > > Thanks, > > Kathleen > > > > Upon closer look, it appears that most of the "No Stipulation" entries > in the BRs are things for which Mozilla would probably want explicit > statements, even though there are no specific BR requirements. > > For example: > > 1.5.1 Organization Administering this document (CP/CPS) > 1.5.3 Person Determining CPS suitability for the Policy > 1.5.4 CPS Approval procedures > 4.3.2 (Mostly relevant to customer relationship) > 4.4.1 (Only relevant to customer relationship) > 4.4.2 Publication of the certificate by the CA > 4.4.3 Notification of certificate issuance by the CA to other entities >(This would cover CT or other mechanisms suitable for CRLset > generation by Mozilla). > 4.5.2 Relying party public key and certificate usage >(This would typically cover disclaiming responsibility if users turn >off revocation checking or interpret the certificate as meaning >something other than a proof of identity of the private key holder). > 4.6 CERTIFICATE RENEWAL >This has been the subject of many discussions about appropriateness of >CA procedures. > Except: > 4.6.4 (Mostly relevant to customer relationship) > 4.6.5 (Only relevant to customer relationship) > 4.7 CERTIFICATE RE-KEY >This has been the subject of many discussions about appropriateness of >CA procedures. > Except: > 4.7.4 (Mostly relevant to customer relationship) > 4.7.5 (Only relevant to customer relationship) > 4.8 CERTIFICATE MODIFICATION >This has much relevance to situations of later discoveries of > discrepancies of changes in circumstances. It is a recurring theme in > discussions about revoking such certificates. > Except: > 4.8.4 (Mostly relevant to customer relationship) > 4.8.5 (Only relevant to customer relationship) > 4.9.4 Revocation Request Grace Period > 4.9.6 Revocation Checking Requirements for Relying Parties >This interacts closely with the features implemented in Mozilla products. > 4.9.8 Maximum Latency for CRLs > 4.10.3 Optional Features (for certificate status services) >This would for example indicate if the OCSP servers provide ways to > distinguish OCSP status for a real certificate and a fake certificate > with the same serial number. If there are OCSP privacy features etc. > 4.11 (Mostly relevant to customer relationship) > 4.12 Key escrow and recovery policy and practices >This is the subject of a Mozilla requirement (not to provide such). > > > > 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 The definition of blank could be integrated into the statement "The words "No Stipulation" mean that the particular document imposes no requirements related to that section." It should be acceptable to leave items blank if they mirror the BR's. Example: 3.2.4 Non-verified Subscriber Information Similarly, when the BR's state "No stipulation" and the CP or CPS corresponds to that same section in that same manner with the agreed definition of no requirements for that section. Example: 4.2.3 Time to Process Certificate Applications No stipulation. Thank you, Joanna ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
On Monday, October 15, 2018 at 11:23:05 AM UTC-7, Kathleen Wilson wrote: > On 10/15/18 11:01 AM, Kathleen Wilson wrote: > > I have added the following section to the Required Practices wiki page: > > > > https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS > > > > > > > > I will continue to appreciate feedback on this update. > > > > Thanks, > > Kathleen > > > Oops... here's the correct link: > > https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647 For clarification on this statement, "Any CPS that falls within the scope of Mozilla’s program must not use the words “No stipulation” unless the corresponding section in the CA/Browser Forum Baseline Requirements state “No stipulation”, “Not applicable”, or is blank." Is the intent to use No stipulation”, “Not applicable”, or blank interchangeably? Thank you, Joanna Fox ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Revocations Due to a Variety of Issues
On Friday, July 20, 2018 at 9:39:04 PM UTC-7, Peter Bowen wrote: > On Fri, Jul 20, 2018 at 6:39 PM Daymion Reynolds via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > The certificates were identified by analyzing results from both zlint and > > certlint. We also verified all lint findings against current and past BRs. > > We discovered multiple defects with the linters, and submitted pull > > requests to correct them. See below. > > > > CertLint PRs to correct issues: > > > > In Progress, will publish if requested. > > > > Yes, I would very much like to have either PRs or just a list of issues. > > > > | e_dnsname_not_valid_tld, | > > | > > |e_subject_common_name_not_from_san,| > > | > > |e_dnsname_bad_character_in_label |4 > > |*7/5/18 11:48 | > > > > > > | e_subject_common_name_not_from_san, | | > > | > > |e_dnsname_bad_character_in_label |28 > > |*7/9/18 21:12 | > > > > > > *Total of 17 certificates issued in 2018 were revoked due to invalid > > extended ascii characters. CertLint was not catching these issues, which > > would have prevented issuance. We have since remediated these problems, and > > are adding zLint to our certificate issuance process as a second check. > > Issued in 2018 certificate serial numbers 4329668077199547083, > > 8815069853166416488, 8835430332440327484, 13229652153750393997, > > 12375089233389451640, 11484792606267277228, 11919098489171585007, > > 9486648889515633287, 14583473664717830410, 7612308405142602244, > > 4011153125742917275, 6919066797946454186, 15449193186990222652, > > 14380872970193550115, 1792501994142248245, 12601193235728728125, > > 10465762057746987360 > > Cert.sh was unavailable when this was crafted else I would provide links > > to the 4 certs which were CT logged. > > > https://crt.sh/?id=294808610=zlint,cablint is one of the > certificates. It is not clear to me that there is an error here. The DNS > names in the SAN are correctly encoded and the Common Name in the subject > has one of the names found in the SAN. The Common Name contains a DNS name > that is the U-label form of one of the SAN entries. > > It is currently undefined if this is acceptable or unacceptable for > certificates covered by the BRs. I put a CA/Browser Forum ballot forward a > while ago to try to clarify it was not acceptable, but it did not pass as > several CAs felt it was not only acceptable but is needed and desirable. > > If Mozilla (or another browser) puts forward a policy on this, I'm happy to > update certlint to reflect the poicy. > > Thanks, > Peter Using the example provided of https://crt.sh/?id=294808610=zlint,cablint, the error to which we were addressing is, “ERROR: Characters in labels of DNSNames MUST be alphanumeric, - , _ or *”. RFC 5280 states that the SAN field can contain a dnsName but it must be in the IA5String format. IA5String is defined as the first 128 characters in the ASCII alphabet. Right now as this is defined, it does not include international variance of ISO 646. Should we revisit this issue to clarify if international characters should be included? GoDaddy would be in support of adding this clarification. Thanks, Joanna ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Namecheap refused to revoke certificate despite domain owner changed
In light of the limited visibility of WHOIS, Wayne's suggestion of "... allow anyone to revoke by proving that they control the domain name using one of the BR 3.2.2.4 methods" is preferable as it is a bit more encompassing rather than restricting to to same validation process. This also supports the idea of transparency around revocation processes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
