Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue
On Mon, Mar 12, 2018 at 11:38 PM jacob.hoffmanandrews--- via dev-security-policy wrote: > On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote: > > Given that Let's Encrypt has been operating a Staging Endpoint ( > > https://letsencrypt.org/docs/staging-environment/ ) for issuing > wildcards, > > what controls, if any, existed to examine the certificate profiles prior > to > > being deployed in production? Normally, that would flush these out - > > through both manual and automated testing, preferably. > > We continuously run our cert-checker tool ( > https://github.com/letsencrypt/boulder/blob/master/cmd/cert-checker/main.go#L196-L261) > in both staging and production. Unfortunately, it tests mainly the higher > level semantic aspects of certificates rather than the lower level encoding > aspects. Clearly we need better coverage on encoding issues. We expect to > get that from integrating more and better linters into both our CI testing > framework and our staging and production environments. We will also review > the existing controls in our cert-checker tool. > > > Golang's ASN.1 library is somewhat lax, largely in part to both public > and > > enterprise CAs' storied history of misencodings. > > Agreed that Go's asn1 package is lax on parsing, but I don't think that it > aims to be lax on encoding; for instance, the mis-encoding of asterisks in > PrintableStrings was considered a bug worth fixing. > > > What examinations, if any, > > will Let's Encrypt be doing for other classes of potential encoding > issues? > > Has this caused any changes in how Let's Encrypt will construct > > TBSCertificates, or review of that code, beyond the introduction of > > additional linting? > > We will re-review the code we use to generate TBSCertificates with an eye > towards encoding issues, thanks for suggesting it. If there are any broad > classes of encoding issues you think are particularly worth watching out > for, that could help guide our analysis. Well, you’ve already run into one of the common ones I’d seen in the past - more commonly with older OpenSSL-based bespoke/enterprise CAs (due to long-since fixed defaults, but nobody upgrading) Encoding of INTEGERS is another frequent source of pain - minimum length encoding, ensuring positive numbers - but given the Go ASN1 package’s author’s hatred of that, I would be surprised. Reordering of SEQUENCES has been an issue for at least two wholly independent CA software stacks when integrating CT support; at least one I suspect is due to using a HashMap that has non-guarantees ordering semantics / iteration order changing between runs and releases. These seems relevant to Go, given its map designs. SET encodings not being sorted according to their values when encoding. This would manifest in DNs, although I don’t believe Boulder supports equivalent RDNs/AVAs. Explicit encoding of DEFAULT values, most commonly basicConstraints. This is issue most commonly crops up when folks convert ASN.1 schemas to internal templates by hand, rather than using compilers - which is something applicable to Go. Not enforcing size constraints - on strings or sequences. Similar to the above, many folks forget to convert the restrictions when converting by hand. Improper encoding of parameter attributes for signature and SPKI algorithms - especially RSA. This is due to the “ANY DEFINED BY” approach and folks hand rolling, or not closely reading the specs. This is more high-level, but derived from the schema flexibility. Variable encoding of string types between Subject/Issuer or Issuer/NameConstraints. This is more quasigrayarea - there are defined semantics for this, but few get it right. This is more high-level, but derived from the schema flexibility. Not realizing DNSName, URI, and rfc822Name nameConstraints have different semantic rules - this is more high-level than encoding, but within that set. certlint/cablint catches many of these, in a large part through using an ASN.1 schema compiler (asn1c) rather than hand-rolling. Yet even it has had some encoding issues in the past. > Also, is this the correct timestamp? For example, examining > > https://crt.sh/?id=353754255&opt=ocsp > > Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a > > revocation time of 2018-03-12 23:58:10 UTC , but you stated your > alerting > > time was 2018-03-13 00:43:00 UTC. I'm curious if that's a bug in the > > display of crt.sh, a typo in your timezone computation (considering the > > recent daylight saving adjustments in the US), a deliberate choice to put > > revocation somewhere between those dates (which is semantically valid, > but > > curious), or perhaps something else. > > I believe this was a timezone computation error. By my reading of the > logs, our alerting time was 2018-03-13 23:43:00 UTC, which agrees with your > hypothesis about the recent timezone change (DST) leading to a mistake in > calculating UTC times. > ___
Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue
On Monday, March 12, 2018 at 8:27:06 PM UTC-7, Ryan Sleevi wrote: > Also, is this the correct timestamp? For example, examining > https://crt.sh/?id=353754255&opt=ocsp > > Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a > revocation time of 2018-03-12 23:58:10 UTC , but you stated your alerting > time was 2018-03-13 00:43:00 UTC. I'm curious if that's a bug in the > display of crt.sh, a typo in your timezone computation (considering the > recent daylight saving adjustments in the US), a deliberate choice to put > revocation somewhere between those dates (which is semantically valid, but > curious), or perhaps something else. Adding a little more detail and precision here: Let's Encrypt backdates certificates by one hour, so "Not Before: Mar 12 22:18:30 2018 GMT" indicates an issuance time of 23:18:30. Also, you may notice that one of the certificates was actually revoked at 23:30:33, before we became aware of the problem. This was done as part of our regular deployment testing, to ensure that revocation was working properly. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue
On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote: > Given that Let's Encrypt has been operating a Staging Endpoint ( > https://letsencrypt.org/docs/staging-environment/ ) for issuing wildcards, > what controls, if any, existed to examine the certificate profiles prior to > being deployed in production? Normally, that would flush these out - > through both manual and automated testing, preferably. We continuously run our cert-checker tool (https://github.com/letsencrypt/boulder/blob/master/cmd/cert-checker/main.go#L196-L261) in both staging and production. Unfortunately, it tests mainly the higher level semantic aspects of certificates rather than the lower level encoding aspects. Clearly we need better coverage on encoding issues. We expect to get that from integrating more and better linters into both our CI testing framework and our staging and production environments. We will also review the existing controls in our cert-checker tool. > Golang's ASN.1 library is somewhat lax, largely in part to both public and > enterprise CAs' storied history of misencodings. Agreed that Go's asn1 package is lax on parsing, but I don't think that it aims to be lax on encoding; for instance, the mis-encoding of asterisks in PrintableStrings was considered a bug worth fixing. > What examinations, if any, > will Let's Encrypt be doing for other classes of potential encoding issues? > Has this caused any changes in how Let's Encrypt will construct > TBSCertificates, or review of that code, beyond the introduction of > additional linting? We will re-review the code we use to generate TBSCertificates with an eye towards encoding issues, thanks for suggesting it. If there are any broad classes of encoding issues you think are particularly worth watching out for, that could help guide our analysis. > Also, is this the correct timestamp? For example, examining > https://crt.sh/?id=353754255&opt=ocsp > Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a > revocation time of 2018-03-12 23:58:10 UTC , but you stated your alerting > time was 2018-03-13 00:43:00 UTC. I'm curious if that's a bug in the > display of crt.sh, a typo in your timezone computation (considering the > recent daylight saving adjustments in the US), a deliberate choice to put > revocation somewhere between those dates (which is semantically valid, but > curious), or perhaps something else. I believe this was a timezone computation error. By my reading of the logs, our alerting time was 2018-03-13 23:43:00 UTC, which agrees with your hypothesis about the recent timezone change (DST) leading to a mistake in calculating UTC times. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Mon, Mar 12, 2018 at 10:53 PM, taher.mestiri--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I asked about fast tracks because it's taking long time to get things > processed related to the fact that all this is running by a community and I > think it can be great to brainstorm ways to handle maybe work overloads > even through paid assessments for example. > I think very few members of this community would see the time it takes to get a publicly trusted CA included as a problem. Indeed, it's actually rather quite the opposite - the time to get a CA included is likely not long enough, the time to get a CA removed is likely not fast enough, and the time for certificates to expire is not short enough. > I hope that you guys can give us a list of major corrections or > verifications to do within a certain limited time to give us the > opportunity to get our CA approved without restarting the whole process. > I hope this is not considered as special treatment as maybe I don't know > what kind of support you provide in such cases. > I shared a number of recommendations, based on the specific incidents highlighted, and the risks they posed. Restarting the whole process is something that has been requested of other CAs with similar deficiencies, because in a large part, this whole ecosystem is based on trust. For a CA to request inclusion, but not demonstrate sufficient technical understanding on how to manage that trust, is reasonable grounds to not trust them. Trust is not automatically granted and then slowly removed - rather, it's slowly earned, based on the quality of character and continued display of trustworthiness. In the case of this inclusion request, both the practices and the policies demonstrated significant gaps from what would be expected. An alternative answer might be to deny inclusion for 2 or more years, since that is often how long it can take to build an organization with both the technical expertise and the implementation to support it, as even the 'best' CAs can attest. However, I tried to offer a more targeted set of suggestions, based on the specific deficiencies that caused trust to be undermined here. While these are only my suggestions, it highlights the problematic patterns on display. In the end, I'm not sure why the Tunisian Government feels it should run a publicly trusted CA, so I don't know if there are other alternatives to suggest that might offer a more expedient, more secure, more reliable basis for trust. If that was to be shared, perhaps there are other solutions that may work. In the absence of that, the failures at the basic and core competencies of being a publicly trusted CA should be concerning. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue
On Mon, Mar 12, 2018 at 11:22 PM, Ryan Sleevi wrote: > > > On Mon, Mar 12, 2018 at 10:35 PM, josh--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> During final tests for the general availability of wildcard certificate >> support, the Let's Encrypt operations team issued six test wildcard >> certificates under our publicly trusted root: >> >> https://crt.sh/?id=353759994 >> https://crt.sh/?id=353758875 >> https://crt.sh/?id=353757861 >> https://crt.sh/?id=353756805 >> https://crt.sh/?id=353755984 >> https://crt.sh/?id=353754255 >> >> These certificates contain a subject common name that includes a “*.” >> label encoded as an ASN.1 PrintableString, which does not allow the >> asterisk character, violating RFC 5280. >> >> We became aware of the problem on 2018-03-13 at 00:43 UTC via the linter >> flagging in crt.sh [1]. > > Also, is this the correct timestamp? For example, examining https://crt.sh/?id=353754255&opt=ocsp Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a revocation time of 2018-03-12 23:58:10 UTC , but you stated your alerting time was 2018-03-13 00:43:00 UTC. I'm curious if that's a bug in the display of crt.sh, a typo in your timezone computation (considering the recent daylight saving adjustments in the US), a deliberate choice to put revocation somewhere between those dates (which is semantically valid, but curious), or perhaps something else. > All six certificates have been revoked. >> >> The root cause of the problem is a Go language bug [2] which has been >> resolved in Go v1.10 [3], which we were already planning to deploy soon. We >> will resolve the issue by upgrading to Go v1.10 before proceeding with our >> wildcard certificate launch plans. >> >> We employ a robust testing infrastructure but there is always room for >> improvement and sometimes bugs slip through our pre-production tests. We’re >> fortunate that the PKI community has produced some great testing tools that >> sometimes catch things we don’t. In response to this incident we are >> planning to integrate additional tools into our testing infrastructure and >> improve our test coverage of multiple Go versions. >> >> [1] https://crt.sh/ >> >> [2] https://github.com/golang/go/commit/3b186db7b4a5cc510e71f906 >> 82732eba3df72fd3 >> >> [3] https://golang.org/doc/go1.10#encoding/asn1 >> >> > Given that Let's Encrypt has been operating a Staging Endpoint ( > https://letsencrypt.org/docs/staging-environment/ ) for issuing > wildcards, what controls, if any, existed to examine the certificate > profiles prior to being deployed in production? Normally, that would flush > these out - through both manual and automated testing, preferably. > > Given that Let's Encrypt is running on an open-source CA (Boulder), this > offers a unique opportunity to highlight where the controls and checks are > in place, particularly for commonNames. RFC 5280 has other restrictions in > place that have tripped CAs up, such as the exclusively using > PrintableString/UTF8String for DirectoryString types (except for backwards > compatibility, which would not apply here), or length restrictions (such as > 64 characters, per the ASN.1 schema), it would be useful to comprehensively > review these controls. > > Golang's ASN.1 library is somewhat lax, largely in part to both public and > enterprise CAs' storied history of misencodings. What examinations, if any, > will Let's Encrypt be doing for other classes of potential encoding issues? > Has this caused any changes in how Let's Encrypt will construct > TBSCertificates, or review of that code, beyond the introduction of > additional linting? > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue
On Mon, Mar 12, 2018 at 10:35 PM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > During final tests for the general availability of wildcard certificate > support, the Let's Encrypt operations team issued six test wildcard > certificates under our publicly trusted root: > > https://crt.sh/?id=353759994 > https://crt.sh/?id=353758875 > https://crt.sh/?id=353757861 > https://crt.sh/?id=353756805 > https://crt.sh/?id=353755984 > https://crt.sh/?id=353754255 > > These certificates contain a subject common name that includes a “*.” > label encoded as an ASN.1 PrintableString, which does not allow the > asterisk character, violating RFC 5280. > > We became aware of the problem on 2018-03-13 at 00:43 UTC via the linter > flagging in crt.sh [1]. All six certificates have been revoked. > > The root cause of the problem is a Go language bug [2] which has been > resolved in Go v1.10 [3], which we were already planning to deploy soon. We > will resolve the issue by upgrading to Go v1.10 before proceeding with our > wildcard certificate launch plans. > > We employ a robust testing infrastructure but there is always room for > improvement and sometimes bugs slip through our pre-production tests. We’re > fortunate that the PKI community has produced some great testing tools that > sometimes catch things we don’t. In response to this incident we are > planning to integrate additional tools into our testing infrastructure and > improve our test coverage of multiple Go versions. > > [1] https://crt.sh/ > > [2] https://github.com/golang/go/commit/3b186db7b4a5cc510e71f90682732e > ba3df72fd3 > > [3] https://golang.org/doc/go1.10#encoding/asn1 > > Given that Let's Encrypt has been operating a Staging Endpoint ( https://letsencrypt.org/docs/staging-environment/ ) for issuing wildcards, what controls, if any, existed to examine the certificate profiles prior to being deployed in production? Normally, that would flush these out - through both manual and automated testing, preferably. Given that Let's Encrypt is running on an open-source CA (Boulder), this offers a unique opportunity to highlight where the controls and checks are in place, particularly for commonNames. RFC 5280 has other restrictions in place that have tripped CAs up, such as the exclusively using PrintableString/UTF8String for DirectoryString types (except for backwards compatibility, which would not apply here), or length restrictions (such as 64 characters, per the ASN.1 schema), it would be useful to comprehensively review these controls. Golang's ASN.1 library is somewhat lax, largely in part to both public and enterprise CAs' storied history of misencodings. What examinations, if any, will Let's Encrypt be doing for other classes of potential encoding issues? Has this caused any changes in how Let's Encrypt will construct TBSCertificates, or review of that code, beyond the introduction of additional linting? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: TunRootCA2 root inclusion request
My reaction was primarily based on the following suggestion: "Generally speaking I would insist on the fact that for country CAs, some kind of fast tracks should be established because the impact of time losing at country level is highly expensive." The answer is, and must be, no. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > taher.mestiri--- via dev-security-policy > Sent: Monday, March 12, 2018 10:54 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: TunRootCA2 root inclusion request > > Dear Tim, > > Not sure your penguin-related example would make the picture sharper or > ideas clearer. > > I asked about fast tracks because it's taking long time to get things processed > related to the fact that all this is running by a community and I think it can be > great to brainstorm ways to handle maybe work overloads even through paid > assessments for example. > > I don't think it's worth to answer either your comments about special > treatment, as no one has asked for it apart of speeding the process which is not > special treatment but respect for users and community, or about how special > we feel we are, etc. > > I am not a member of the government, I consider myself member of an open > global IT community, including but not limited to mozilla, that shares same > values of respect and mutual help. I find your answer a bit aggressive but, > anyway, maybe I was wrong about something that made you answer the way > you did... That was not my intention. > > I hope that you guys can give us a list of major corrections or verifications to do > within a certain limited time to give us the opportunity to get our CA approved > without restarting the whole process. > I hope this is not considered as special treatment as maybe I don't know what > kind of support you provide in such cases. > > At the end, I would reiterate that I shared personal opinions and I am not > member of the government as this is a public open discussion and I don't want > that my opinion impacts negaively the decision taking. > > Best, > > Taher. > > > > On Tuesday, 13 March 2018 03:06:40 UTC+1, Tim Hollebeek wrote: > > Nobody is blocking any country from advancing. There are no Mozilla > > rules that prevent any country from having the best CA on the planet. > > If a bunch of penguins at McMurdo station run an awesome CA, I'll ask > > some hard questions about how they meet the OCSP requirements with > > their limited bandwidth, but if they have good answers, I'm fine with > > internet security now being penguins all the way down. > > > > If you want your certificates to be accepted everywhere on the planet, > > you need to follow the same rules as everyone else on the planet. No > > fast tracks or special rules for anyone, no matter how special they > > feel they are. > > > > The same rules for everyone is the only sane route forward. > > Governments often believe they deserve special treatment, and they may > > have the ability to force that to be true within their own country, > > but that doesn't make it a good idea for Mozilla. > > > > -Tim > > > > > -Original Message- > > > From: dev-security-policy [mailto:dev-security-policy- > > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > > > taher.mestiri--- via dev-security-policy > > > Sent: Monday, March 12, 2018 7:31 PM > > > To: mozilla-dev-security-pol...@lists.mozilla.org > > > Subject: Re: TunRootCA2 root inclusion request > > > > > > Dear All, > > > > > > Thank you for your detailed description of your concerns with the > > > Tunisian > > CA. > > > > > > I have been one of those guys that developped IT communities for > > > more than > > 7 > > > years in Tunisia, starting by Tunandroid (Tunisian Android > > > Community), > > Google > > > Developers Groups, organized the best Software Freedom Day in 2012, > > > supported local Mozilla Community 2013-2014, GDG Country Champion in > > > Tunisia 2012-2014 and represented the IT community in law projects > > > to help developing the local ecosystem since 2013 and still. > > > > > > The reason why I am telling you this is to assure you that I > > > perfectly > > understand > > > what a community is about: helping each others, making things better > > > and sharing knowledge. Things have always been inclusive. > > > > > > The Tunisian national digital certification agency has been under > > > pressure > > for > > > more then 3 years to have its CA certificates recognized by Mozilla > > > and > > they did > > > all which is possible to do to have the best security standards when > > > they > > got > > > audited and criticized and they have alwyas been very reactive. > > > > > > I would highlight that we are speaking here about a national CA > > > which is completely different from any other type of agencies. We > > > are speaking > > about > > > blocking a whole
Re: TunRootCA2 root inclusion request
Dear Tim, Not sure your penguin-related example would make the picture sharper or ideas clearer. I asked about fast tracks because it's taking long time to get things processed related to the fact that all this is running by a community and I think it can be great to brainstorm ways to handle maybe work overloads even through paid assessments for example. I don't think it's worth to answer either your comments about special treatment, as no one has asked for it apart of speeding the process which is not special treatment but respect for users and community, or about how special we feel we are, etc. I am not a member of the government, I consider myself member of an open global IT community, including but not limited to mozilla, that shares same values of respect and mutual help. I find your answer a bit aggressive but, anyway, maybe I was wrong about something that made you answer the way you did... That was not my intention. I hope that you guys can give us a list of major corrections or verifications to do within a certain limited time to give us the opportunity to get our CA approved without restarting the whole process. I hope this is not considered as special treatment as maybe I don't know what kind of support you provide in such cases. At the end, I would reiterate that I shared personal opinions and I am not member of the government as this is a public open discussion and I don't want that my opinion impacts negaively the decision taking. Best, Taher. On Tuesday, 13 March 2018 03:06:40 UTC+1, Tim Hollebeek wrote: > Nobody is blocking any country from advancing. There are no Mozilla rules > that prevent any country from having the best CA on the planet. If a bunch > of penguins at McMurdo station run an awesome CA, I'll ask some hard > questions about how they meet the OCSP requirements with their limited > bandwidth, but if they have good answers, I'm fine with internet security > now being penguins all the way down. > > If you want your certificates to be accepted everywhere on the planet, you > need to follow the same rules as everyone else on the planet. No fast > tracks > or special rules for anyone, no matter how special they feel they are. > > The same rules for everyone is the only sane route forward. Governments > often believe they deserve special treatment, and they may have the ability > to force that to be true within their own country, but that doesn't make it > a good idea for Mozilla. > > -Tim > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > > taher.mestiri--- via dev-security-policy > > Sent: Monday, March 12, 2018 7:31 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: TunRootCA2 root inclusion request > > > > Dear All, > > > > Thank you for your detailed description of your concerns with the Tunisian > CA. > > > > I have been one of those guys that developped IT communities for more than > 7 > > years in Tunisia, starting by Tunandroid (Tunisian Android Community), > Google > > Developers Groups, organized the best Software Freedom Day in 2012, > > supported local Mozilla Community 2013-2014, GDG Country Champion in > > Tunisia 2012-2014 and represented the IT community in law projects to help > > developing the local ecosystem since 2013 and still. > > > > The reason why I am telling you this is to assure you that I perfectly > understand > > what a community is about: helping each others, making things better and > > sharing knowledge. Things have always been inclusive. > > > > The Tunisian national digital certification agency has been under pressure > for > > more then 3 years to have its CA certificates recognized by Mozilla and > they did > > all which is possible to do to have the best security standards when they > got > > audited and criticized and they have alwyas been very reactive. > > > > I would highlight that we are speaking here about a national CA which is > > completely different from any other type of agencies. We are speaking > about > > blocking a whole country from advancing. > > > > It's already unacceptable to have such long process for country CA, if we > have > > to fail and restart we have to fail quickly because time is very valuable. > We > > can't afford restarting the process if the Tunisian CA gets rejected but > instead I > > think anything can be corrected and updated this is how I.T. works. > > > > Generally speaking I would insist on the fact that for country CAs, some > kind of > > fast tracks should be established because the impact of time losing at > country > > level is highly expensive. > > > > I have no doubt about your support and hope you can help my country move > > forward and I am sure that the team in our national digital certification > agency > > will do its best to assure you about how seriously we are working to make > > users globally trusting
2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue
During final tests for the general availability of wildcard certificate support, the Let's Encrypt operations team issued six test wildcard certificates under our publicly trusted root: https://crt.sh/?id=353759994 https://crt.sh/?id=353758875 https://crt.sh/?id=353757861 https://crt.sh/?id=353756805 https://crt.sh/?id=353755984 https://crt.sh/?id=353754255 These certificates contain a subject common name that includes a “*.” label encoded as an ASN.1 PrintableString, which does not allow the asterisk character, violating RFC 5280. We became aware of the problem on 2018-03-13 at 00:43 UTC via the linter flagging in crt.sh [1]. All six certificates have been revoked. The root cause of the problem is a Go language bug [2] which has been resolved in Go v1.10 [3], which we were already planning to deploy soon. We will resolve the issue by upgrading to Go v1.10 before proceeding with our wildcard certificate launch plans. We employ a robust testing infrastructure but there is always room for improvement and sometimes bugs slip through our pre-production tests. We’re fortunate that the PKI community has produced some great testing tools that sometimes catch things we don’t. In response to this incident we are planning to integrate additional tools into our testing infrastructure and improve our test coverage of multiple Go versions. [1] https://crt.sh/ [2] https://github.com/golang/go/commit/3b186db7b4a5cc510e71f90682732eba3df72fd3 [3] https://golang.org/doc/go1.10#encoding/asn1 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: TunRootCA2 root inclusion request
Nobody is blocking any country from advancing. There are no Mozilla rules that prevent any country from having the best CA on the planet. If a bunch of penguins at McMurdo station run an awesome CA, I'll ask some hard questions about how they meet the OCSP requirements with their limited bandwidth, but if they have good answers, I'm fine with internet security now being penguins all the way down. If you want your certificates to be accepted everywhere on the planet, you need to follow the same rules as everyone else on the planet. No fast tracks or special rules for anyone, no matter how special they feel they are. The same rules for everyone is the only sane route forward. Governments often believe they deserve special treatment, and they may have the ability to force that to be true within their own country, but that doesn't make it a good idea for Mozilla. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > taher.mestiri--- via dev-security-policy > Sent: Monday, March 12, 2018 7:31 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: TunRootCA2 root inclusion request > > Dear All, > > Thank you for your detailed description of your concerns with the Tunisian CA. > > I have been one of those guys that developped IT communities for more than 7 > years in Tunisia, starting by Tunandroid (Tunisian Android Community), Google > Developers Groups, organized the best Software Freedom Day in 2012, > supported local Mozilla Community 2013-2014, GDG Country Champion in > Tunisia 2012-2014 and represented the IT community in law projects to help > developing the local ecosystem since 2013 and still. > > The reason why I am telling you this is to assure you that I perfectly understand > what a community is about: helping each others, making things better and > sharing knowledge. Things have always been inclusive. > > The Tunisian national digital certification agency has been under pressure for > more then 3 years to have its CA certificates recognized by Mozilla and they did > all which is possible to do to have the best security standards when they got > audited and criticized and they have alwyas been very reactive. > > I would highlight that we are speaking here about a national CA which is > completely different from any other type of agencies. We are speaking about > blocking a whole country from advancing. > > It's already unacceptable to have such long process for country CA, if we have > to fail and restart we have to fail quickly because time is very valuable. We > can't afford restarting the process if the Tunisian CA gets rejected but instead I > think anything can be corrected and updated this is how I.T. works. > > Generally speaking I would insist on the fact that for country CAs, some kind of > fast tracks should be established because the impact of time losing at country > level is highly expensive. > > I have no doubt about your support and hope you can help my country move > forward and I am sure that the team in our national digital certification agency > will do its best to assure you about how seriously we are working to make > users globally trusting our CA protected. > > Best regards, > > Taher Mestiri > > > > On Monday, 12 March 2018 15:59:55 UTC+1, Ryan Sleevi wrote: > > These responses demonstrate why the request is troubling. They attempt > > to paint it as "other people do it" > > > > The risk of removing an included CA must balance the ecosystem > > disruption to those non-erroneous certs, while the risk to ecosystem > > inclusion needs to balance both the aggregate harm to the ecosystem > > (through lowered > > standards) and the risk to the ecosystem of rejecting the request (of > > which, until inclusion is accepted, is low) > > > > The pattern of issues - particularly for a new CA - is equally problematic. > > A CA, especially in light of the public discussions, should not be > > having these issues in 2018, and yet, here we are. > > > > We are in agreement on the objective facts - namely, that there is a > > prolonged pattern of issues - and the criteria - namely, that CAs > > should adhere to the policy in requesting inclusion. A strict > > adherence to those objectives would be to fully deny the request. It > > sounds like where we disagree, then, is not in the objective facts and > > criteria, but rather, where the evaluation of that leaves relative to risk. > > > > The position I am advocating is that, even if these individual matters > > might be seen as less risky, especially, as has been mentioned, this > > CA is "only" intended for .tn for the most case, the existence of such > > a pattern (and the means of acknowledging-but-not-resolving-completely > > these issues) is indicative that there will continue to be serious > > issues, and that the risk is not simply limited to .tn, but threatens > > global Internet stability an
Re: TunRootCA2 root inclusion request
Dear All, Thank you for your detailed description of your concerns with the Tunisian CA. I have been one of those guys that developped IT communities for more than 7 years in Tunisia, starting by Tunandroid (Tunisian Android Community), Google Developers Groups, organized the best Software Freedom Day in 2012, supported local Mozilla Community 2013-2014, GDG Country Champion in Tunisia 2012-2014 and represented the IT community in law projects to help developing the local ecosystem since 2013 and still. The reason why I am telling you this is to assure you that I perfectly understand what a community is about: helping each others, making things better and sharing knowledge. Things have always been inclusive. The Tunisian national digital certification agency has been under pressure for more then 3 years to have its CA certificates recognized by Mozilla and they did all which is possible to do to have the best security standards when they got audited and criticized and they have alwyas been very reactive. I would highlight that we are speaking here about a national CA which is completely different from any other type of agencies. We are speaking about blocking a whole country from advancing. It's already unacceptable to have such long process for country CA, if we have to fail and restart we have to fail quickly because time is very valuable. We can't afford restarting the process if the Tunisian CA gets rejected but instead I think anything can be corrected and updated this is how I.T. works. Generally speaking I would insist on the fact that for country CAs, some kind of fast tracks should be established because the impact of time losing at country level is highly expensive. I have no doubt about your support and hope you can help my country move forward and I am sure that the team in our national digital certification agency will do its best to assure you about how seriously we are working to make users globally trusting our CA protected. Best regards, Taher Mestiri On Monday, 12 March 2018 15:59:55 UTC+1, Ryan Sleevi wrote: > These responses demonstrate why the request is troubling. They attempt to > paint it as "other people do it" > > The risk of removing an included CA must balance the ecosystem disruption > to those non-erroneous certs, while the risk to ecosystem inclusion needs > to balance both the aggregate harm to the ecosystem (through lowered > standards) and the risk to the ecosystem of rejecting the request (of > which, until inclusion is accepted, is low) > > The pattern of issues - particularly for a new CA - is equally problematic. > A CA, especially in light of the public discussions, should not be having > these issues in 2018, and yet, here we are. > > We are in agreement on the objective facts - namely, that there is a > prolonged pattern of issues - and the criteria - namely, that CAs should > adhere to the policy in requesting inclusion. A strict adherence to those > objectives would be to fully deny the request. It sounds like where we > disagree, then, is not in the objective facts and criteria, but rather, > where the evaluation of that leaves relative to risk. > > The position I am advocating is that, even if these individual matters > might be seen as less risky, especially, as has been mentioned, this CA is > "only" intended for .tn for the most case, the existence of such a pattern > (and the means of acknowledging-but-not-resolving-completely these issues) > is indicative that there will continue to be serious issues, and that the > risk is not simply limited to .tn, but threatens global Internet stability > and security. Given that the number of certificates being issued are, from > your own descriptions, aimed to be measured in the hundreds, further > highlights that the risk is rather substantial. > > On Mon, Mar 12, 2018 at 2:14 AM, Anis via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hi Ryan > > I am so sorry but is the same error. > > CN NAME NOT INCLUDE IN THE SAN > > Local IP ADRESS > > Policy not upto date > > Is clear for me and i understand. > > All this error became from approuved authority. Is the risk no. > > Then The ecosystem is not protected! > > ANIS > > ___ > > 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: DigiCert .onion certificates without Tor Service Descriptor Hash extension
Thanks, Jeremy. I also found a certificate [1] with both 16-character.onion and 56-character.onion addresses [2] listed in the SAN. The v3 address is not included in the 2.23.140.1.31 extension, which seems to violate the same rule as below. However, v3 addresses include the service's entire public key in the address itself, so there's nothing to be gained by embedding a hash of that key in a certificate. I'm not sure what, if anything, needs to happen in this case. Thoughts? Alex [1] https://crt.sh/?id=351449246 [2] https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt On Mon, Mar 12, 2018 at 7:28 PM, Jeremy Rowley via dev-security-policy wrote: > Thanks Alex. Sorry for the delayed response. I've been traveling today. > We're reaching out to each of the customers and getting their cert replaced. > > > Looking into this, we did not correctly implement the ballot: > 1. We didn't add a check to our backend system too verify the cert included > a descriptor prior to issuance. > 2. On the front end, we missed requiring a Tor descriptor prior to > processing the order. > 3. The validation team received insufficient training on the Tor descriptor > requirement. > > In reality, the issue was too much reliance on the human component of > asserting the Tor descriptors instead of having a technical control in > place. We're working on putting those technical controls in place. > > Jeremy > > -Original Message- > From: dev-security-policy > > On Behalf Of Alex Cohn via dev-security-policy > Sent: Sunday, March 11, 2018 9:37 PM > To: dev-security-policy@lists.mozilla.org > Subject: DigiCert .onion certificates without Tor Service Descriptor Hash > extension > > In the EV Guidelines [1], Appendix F states "The CA MUST include the CAB > Forum Tor Service Descriptor Hash extension in the TBSCertificate convey > hashes of keys related to .onion addresses." This language was added in > Ballot 201 [2], which had an effective date of 8 July 2017. > > The following certificates (and precertificates if the corresponding > certificate is not in a public CT log) were issued by DigiCert after 8 July > for .onion domains, but lack the necessary extension: > https://crt.sh/?q=240277340 (revoked 26 October 2017) > https://crt.sh/?q=261570255 > https://crt.sh/?q=261570338 > https://crt.sh/?q=261570380 > https://crt.sh/?q=261570384 > https://crt.sh/?q=261579788 > https://crt.sh/?q=261601212 > https://crt.sh/?q=261601280 > https://crt.sh/?q=261601281 > https://crt.sh/?q=261601284 > https://crt.sh/?q=261988060 > https://crt.sh/?q=326491168 > https://crt.sh/?q=326830043 > https://crt.sh/?q=328308725 > https://crt.sh/?q=328961187 > https://crt.sh/?q=329559222 > https://crt.sh/?q=330180704 > https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email to > DigiCert) > > This was previously discussed on m.d.s.p about a year ago [3]. > > [1] > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6. > 8.pdf > [2] https://cabforum.org/2017/06/08/2427/ > [3] > https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/ZtNI > D_xfAgAJ > ___ > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension
Thanks Alex. Sorry for the delayed response. I've been traveling today. We're reaching out to each of the customers and getting their cert replaced. Looking into this, we did not correctly implement the ballot: 1. We didn't add a check to our backend system too verify the cert included a descriptor prior to issuance. 2. On the front end, we missed requiring a Tor descriptor prior to processing the order. 3. The validation team received insufficient training on the Tor descriptor requirement. In reality, the issue was too much reliance on the human component of asserting the Tor descriptors instead of having a technical control in place. We're working on putting those technical controls in place. Jeremy -Original Message- From: dev-security-policy On Behalf Of Alex Cohn via dev-security-policy Sent: Sunday, March 11, 2018 9:37 PM To: dev-security-policy@lists.mozilla.org Subject: DigiCert .onion certificates without Tor Service Descriptor Hash extension In the EV Guidelines [1], Appendix F states "The CA MUST include the CAB Forum Tor Service Descriptor Hash extension in the TBSCertificate convey hashes of keys related to .onion addresses." This language was added in Ballot 201 [2], which had an effective date of 8 July 2017. The following certificates (and precertificates if the corresponding certificate is not in a public CT log) were issued by DigiCert after 8 July for .onion domains, but lack the necessary extension: https://crt.sh/?q=240277340 (revoked 26 October 2017) https://crt.sh/?q=261570255 https://crt.sh/?q=261570338 https://crt.sh/?q=261570380 https://crt.sh/?q=261570384 https://crt.sh/?q=261579788 https://crt.sh/?q=261601212 https://crt.sh/?q=261601280 https://crt.sh/?q=261601281 https://crt.sh/?q=261601284 https://crt.sh/?q=261988060 https://crt.sh/?q=326491168 https://crt.sh/?q=326830043 https://crt.sh/?q=328308725 https://crt.sh/?q=328961187 https://crt.sh/?q=329559222 https://crt.sh/?q=330180704 https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email to DigiCert) This was previously discussed on m.d.s.p about a year ago [3]. [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6. 8.pdf [2] https://cabforum.org/2017/06/08/2427/ [3] https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/ZtNI D_xfAgAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-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
Mozilla Security Blog re Symantec TLS Certs
All, Wayne and I have posted a Mozilla Security Blog regarding the current plan for distrusting the Symantec TLS certs. https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/ Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Following up on Trustico: reseller practices and accountability
You might be interested in the following blog post: https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practice s/ We are continuing to look into whether there are any additional partners or resellers that are misbehaving. This may indeed be an area where stricter requirements are necessary, though it's a complicated problem. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Eric Mill > via dev-security-policy > Sent: Sunday, March 11, 2018 1:16 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Following up on Trustico: reseller practices and accountability > > Though I'm not a GlobalSign customer, I'm told that GlobalSign sent the > following email to its partner ecosystem: > > Dear Partner, > > In reaction to current events related to the private key exposure and mass > revocation by Trustico/Digicert, GlobalSign is reaching out to its trusted > Partners and Resellers to survey how they approach customer private key and > CSR generation. The most secure method is to generate the keys on the server > and then use the CSR when requesting the certificate. If you do generate > private keys for any of your customers outside of the web server environment > where the certificate will be hosted, we request that you stop this practice > immediately. > > We ask that all Partners and Resellers complete the following short > questionnaire as soon as possible or by: Friday, March 16, 2018. > > Compliance questionnaire : [REDACTED] > Note: Only one questionnaire needs to be completed per company. > > Thank you in advance for your cooperation and attention to this important > topic. > > Kind regards, > GlobalSign Security and Compliance > > > So it's nice to see that at least one CA is taking action on this topic without > being ordered to (that I'm aware of). Obviously not all resellers are like Trustico > and perform only a straight certificate pass-through, as Ryan Sleevi pointed > out, and key escrow is a necessary part of acting as a host, or CDN, or other > authorized representative. > > But surely there is still some way to responsibly look through the ecosystem for > resellers that do not perform an authorized function that requires key escrow. > Are any other CAs willing to do something like GlobalSign has done? > > Also, it would be very helpful if GlobalSign could share some information > relating to the responses they get, even if they are aggregated or anonymized. > > -- Eric > > On Sun, Mar 4, 2018 at 4:04 PM, Eric Mill wrote: > > > Last week, Trustico (a reseller, formerly for Symantec and now for > > Comodo) sent 23,000 private keys to DigiCert, to force their > > revocation. This showed that Trustico had been storing customer keys > > generated through one or more CSR/key generation forms on their website. > > > > Though Trustico disagrees, this appears to be a clear case of routine > > key compromise for subscribers who obtained their key from Trustico. > > The security of Trustico's systems, which are not audited or > > accountable to root program requirements, were storing large amounts > > of key material whose compromise could have led to the subsequent > > compromise of connections to tens of thousands of online services. > > > > It was also noted that Trustico was exposing key material to > > interception by a number of third parties through client-side > > JavaScript embeds, and that Trustico's website had functionality that > > allowed remote code execution as root on one of their web servers. > > > > These m.d.s.p threads document/link to those things: > > > > * https://groups.google.com/d/topic/mozilla.dev.security. > > policy/wxX4Yv0E3Mk/discussion > > * https://groups.google.com/d/topic/mozilla.dev.security. > > policy/BLvabFwcJqo/discussion > > > > As part of the second thread, Comodo noted: > > > > We also asked Trustico to cease offering any tools to generate and/or > > retain customer private keys. They have complied with this request > > and have confirmed that they do not intend to offer any such tools > > again in the future. > > > > > > That is good to hear, but a "we won't do it again" response, if > > accepted by Comodo as sufficient, seems disproportionate to the > > severity of the issue, given Trustico's unfamiliarity with norms > > around private key management, and with basic security practices. > > > > It's also clear from the experience that rules of the road for > > resellers are unclear, and that accountability is limited. It seems > > possible, or likely, that other resellers may also be mishandling > > customer keys > > > > So, what would useful next steps be to improve security and > > accountability for resellers? > > > > One thought: Mozilla could ask CAs to obtain a written response from > > all contracted resellers about if/how they interact with customer key > > material, including the level of iso
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
Hi Wayne Here my answers to the ==Meh== questions. 1 * Camerfirma has had a number of recent compliance issues as listed below: Resolved: * Non-BR-compliant OCSP responders: https://bugzilla.mozilla.org/show_bug.cgi?id=1426233 * CAA checking failure: https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 * Duplicate SANs and without localityName or stateOrProvinceName: https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 * Invalid DNS Names: https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 (just resolved today) Still Open: * Non-printable characters in OU field: https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 (this issue was reported by Camerfirma) RMM --> We are working on the "still open" bug to close it as soon as possible. 2 * CPS [5] section 1.2.1.1 appears to exempt test certificates from BR requirements. RMM --> AC Camerfirma do not issue SSL test certificates anymore. AC Camerfirma will clarify this issue in the next CPS version 3 * Section 3.1.8.2.2 of the CPS implies that CAA checking is done manually. While this isn’t forbidden, it is easily susceptible to errors. RMM --> See https://bugzilla.mozilla.org/show_bug.cgi?id=1390977. At the moment a non-technical check over the CAA value is done by the RA Operator before issue any certificate. We plan to have the CAA technical control in March 2018, 4 * CPS section 1.2.1.4.1.3 states that the GCSR2016 “is only used for the purpose of carrying out the accreditation processes with different browsers.” We recently decided to relax the requirements for inclusion, but this statement does imply that there is no value to Mozilla users in enabling the websites trust bit for this root. RMM --> We use this Root as a possible contingency. We would like to keep it as it. If the community considers it's a risk, AC Camerfirma has no objection to leave it out of the scope. 5 * CPS section 1.5.5 indicates that delegated RAs are permitted, but it does not clearly indicate that domain validation functions may not be delegated. RMM -> AC Camerfirma will clarify this issue in the next CPS version. Since it was stated by BR AC Camerfirma has always performed domain validation. 6 * CPS section 2.5.3 states that “Camerfirma currently offers the OCSP service free-of-charge but reserves the right to invoice for these services.” If OCSP service were to be blocked for all but paying users, I believe that would be a BR violation. RMM -> AC Camerfirma will correct this issue in the next CPS version. Nevertheless AC Camerfirma never ever has charged for OCSP access. BR Ramiro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
These responses demonstrate why the request is troubling. They attempt to paint it as "other people do it" The risk of removing an included CA must balance the ecosystem disruption to those non-erroneous certs, while the risk to ecosystem inclusion needs to balance both the aggregate harm to the ecosystem (through lowered standards) and the risk to the ecosystem of rejecting the request (of which, until inclusion is accepted, is low) The pattern of issues - particularly for a new CA - is equally problematic. A CA, especially in light of the public discussions, should not be having these issues in 2018, and yet, here we are. We are in agreement on the objective facts - namely, that there is a prolonged pattern of issues - and the criteria - namely, that CAs should adhere to the policy in requesting inclusion. A strict adherence to those objectives would be to fully deny the request. It sounds like where we disagree, then, is not in the objective facts and criteria, but rather, where the evaluation of that leaves relative to risk. The position I am advocating is that, even if these individual matters might be seen as less risky, especially, as has been mentioned, this CA is "only" intended for .tn for the most case, the existence of such a pattern (and the means of acknowledging-but-not-resolving-completely these issues) is indicative that there will continue to be serious issues, and that the risk is not simply limited to .tn, but threatens global Internet stability and security. Given that the number of certificates being issued are, from your own descriptions, aimed to be measured in the hundreds, further highlights that the risk is rather substantial. On Mon, Mar 12, 2018 at 2:14 AM, Anis via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan > I am so sorry but is the same error. > CN NAME NOT INCLUDE IN THE SAN > Local IP ADRESS > Policy not upto date > Is clear for me and i understand. > All this error became from approuved authority. Is the risk no. > Then The ecosystem is not protected! > ANIS > ___ > 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: TunRootCA2 root inclusion request
Hi Ryan I am so sorry but is the same error. CN NAME NOT INCLUDE IN THE SAN Local IP ADRESS Policy not upto date Is clear for me and i understand. All this error became from approuved authority. Is the risk no. Then The ecosystem is not protected! ANIS ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
> 1 * The inclusion request references a much older CPS [3] that doesn't > list the 2016 versions of these roots or comply with current policies. > I only reviewed the newer CPS [5], but this CPS (section 1.2.1) > doesn't cover the older roots that are currently included. I believe > this is a compliance issue with the currently included AC Camerfirma roots. > > RMM -> EIDAS regulation has been an important milestone that took us > to consider to setup a new hierarchy (2016) and writing a new CPS > apart from the other hierarchies and CPS, even more when our final > target is to distribute certificates only from the 2016 hierarchy. > This request to incorporate the new 2016 roots affects only to eIDAS > CPS (1.2.1). However, the CPS –no eIDAS (3.2.7) are still valid for > the hierarchies (2003 and 2008). > > Roots from the older hierarchies are currently included in the Mozilla > CA program, but the CPS that applies to these roots does not comply with > Mozilla policy (it hasn't been revised since 2015) - is that correct? If so, > how and when do you intend to correct the problem? RMM -> Certainly we have focused on the eIDAS CPS roots 2016 that is affecting this bug. Although the CPS version of the root (2003 and 2008) is dated 2015, procedures and controls used to issue SSL certificates are the same for all roots and fulfill the BR requirements as indicated by our WEBTRUST CA,BR,EVaudit reports. We are currently working on both DPC to fulfill the requirement of adaptation to the RFC3647 structure required by CABFORUM. We plan to publish them next April. In any case we will publish them before 2018-05-31 limit required by CABFORUM providing a solution to this issue. Although we would like wait for the April RFC3647 adapted version, If the community consider that a version should be publish immediately, AC Camerfirma have no objection to do that. Regards Ramiro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
SwissSign: Cert issued with a to long validity period
to whom it may concern Last week we have reported a Bug on https://bugzilla.mozilla.org/show_bug.cgi?id=1443731 about a certificate we issued with a to long validity period. We are now asked to publish the same incident report also on this mozilla.dev.security.policy forum: Topic 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. On the evening of 6th March 2018 our CABLint post-issue test system alerted us to this problem. We also received emails from an external source Topic 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. 2018-03-06 15:49 UTC The certificate was issued 2018-03-07 06:00 UTC We started an investigation 2018-03-07 07:00 UTC We contacted the customer in order to replace the certificate and revoke the mis-issued one 2018-03-07 12:36 UTC The certificate was revoked Topic 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 identified the source of the problem as incorrect use of a rarely used reissue option available only to SwissSign support employees. We immediately prohibited any use of this functionality until the option is fixed (ETA 17th March 2018). Topic 4: A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. https://crt.sh/?id=348592796&opt=zlint,cablint Topic 5: 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. See https://crt.sh/?id=348592796&opt=zlint,cablint Topic 6: Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The support option in question was not in scope during the initial work to implement ballot 193 - it was planned to be implemented by 17th March 2018. During the interim period support staff were trained to use the functionality with caution and in accordance with the requirements. Topic 7: 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. Immediate action: We have prohibited any use of the problematic reissue functionality until it is technically constrained to 825 days for SSL certificates 7th March 2018: The fixes for the reissue functionality have been rolled out to our test environment 17th March 2018: The fixes for the reissue functionality will be rolled out in production ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
