Re: CA Communication: Underscores in dNSNames
On Tue, Dec 18, 2018 at 3:47 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Removing the "underscore mandatory" and "specific name X_Y mandatory" > rules > from deployed systems without introducing security holes takes more than > the > 1 month they have given that the annual Thanksgiving-to-NewYears lockdown > has been mentioned in other global issues. (In fact this is the first > subscriber/RP interfering BR effective date hitting the Xmas season since > the SHA-1 deprecation). > > The only thing that's required by 15-Jan is that existing certificates containing underscores need to be replaced with new ones with the same dNSNames. The deadline for updating systems to remove dependencies on underscores in certificates is 30-April. The 15-Jan deadline was negotiated with holiday change freezes in mind. The assumption was that these freezes end in early January, providing sufficient time to perform a routine certificate replacement. While I understand that the replacement is not necessarily as simple as it should be for all affected systems, and in other cases it's simple but there are lots of certificates to replace, I think this is really just highlighting the lack of agility in existing enterprise systems that use publicly-trusted certificates. Hopefully this "huge mess" will spur improvements over time. I am also struggling with the argument that "revoking these certificates will cause a massive outage, but we can't replace them due to our change freeze." Given this position, I sincerely hope that no severe zero-days are released during the holidays. ___ 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
On 18/12/2018 18:15, Ryan Sleevi wrote: > On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 10/12/2018 18:09, Ryan Sleevi wrote: >>> On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy < >>> dev-security-policy@lists.mozilla.org> wrote: >>> Hello! It would be helpful, if the CA/B or Mozilla could publish a document on its web pages to which we can redirect our customers, if they have technical questions about this underscore issue. Right now, I can only >> tell them, that they are forbidden because the ballot to explicitly allow >> them failed, but not really why. Especially since the first result in Google >> for "underscore domain name" is a StackOverflow article ( https://stackoverflow.com/a/2183140/1426535) stating that it is technically perfectly okay and also RFC 5280 says "These characters [underscore and at-sign] often appear in Internet addresses. Such addresses MUST be encoded using an ASN.1 type that supports them." >>> >>> There's definitely been a lot of back and forth on this topic. It's >> unclear >>> if you're looking for a clearer statement about why they're forbidden or >>> where they're forbidden. >>> >> >> It is clear that Rufus is looking for a link to the deprecation ballot, >> rather than the old (failed) non-deprecation ballot. >> > > Thanks for sharing your interpretation. I don't think that is an accurate > summary, but it's useful to understand your perspective and how you > interpret things. > Well he wanted that or another _single document_ that affected parties can read, rather than trying to dig through the RFCs and mailing lists themselves. > >>> If the question is where they are forbidden, >>> https://tools.ietf.org/html/rfc5280#section-4.2.1.6 >>> >>> When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax", as specified by Section 3.5 of [RFC1034] and as modified by Section 2.1 of [RFC1123]. Note that while uppercase and lowercase letters are allowed in domain names, no significance is attached to the case. >> In addition, while the string " " is a legal domain name, >> subjectAltName extensions with a dNSName of " " MUST NOT be used. Finally, the use of the DNS representation for Internet mail addresses (subscriber.example.com instead of subscri...@example.com) MUST NOT be used; such identities are to be encoded as rfc822Name. Rules for encoding internationalized domain names are specified in Section >> 7.2. >>> >> >> The huge mess comes from the fact that this requirement of not >> using the underscore character (which is actually used in some >> RFC-specified DNS names labels, though for special purposes) was >> buried in a complicated reference to two old RFCs, each of which >> in turn describe that particular restriction in a complicated and >> indirect way. >> > > I find your summary interesting. I presume, then, that you feel that the > need to use DNS is buried in complicated references to old RFCs, much as it > would be how HTTP works or, for that matter, how ASN.1 works. It's > certainly true that, as we build complex systems, we stand on the shoulder > of giants, and as we build code and systems, we layer them. I think it's > rather misguided and ignorant to suggest that, because a document is > referenced by another document, it somehow becomes complicated, or that the > age matters. Were that the case, we'd presume the Baseline Requirements > would include everything from the IP specification to the ASN.1 > specification, and everything in between, and then lament at how anyone is > supposed to understand or maintain the salient bits of this 10,000 page > document. > The simple fact that the leading experts on the subject disagreed on the issue shows that the outcome wasn't obvious (the opposite outcome would not have been obvious either). It's the classic question if corner case behavior of a piece of code is a feature or a bug, except it was English-language documents, not C-language code. The wording and structure of RFC5280 (and its predecessor RFC2459) is such that it appears to state an encoding of DNS names, not a restriction to ARPANET host names. For a subscriber or relying party developing and deploying a system like the one described by pilgrim2223, everything after the 2nd paragraph of 4.2.1.6 would look like ASN.1/DER encoding details to be handled by the 3rd party TLS library, and such a subscriber would probably believe it when both a Google search and their CA tells them it is A-OK. Removing the "underscore mandatory" and "specific name X_Y mandatory" rules from deployed systems without introducing security holes takes
Re: CA Communication: Underscores in dNSNames
On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 10/12/2018 18:09, Ryan Sleevi wrote: > > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> Hello! > >> > >> It would be helpful, if the CA/B or Mozilla could publish a document on > >> its web pages to which we can redirect our customers, if they have > >> technical questions about this underscore issue. Right now, I can only > tell > >> them, that they are forbidden because the ballot to explicitly allow > them > >> failed, but not really why. Especially since the first result in Google > for > >> "underscore domain name" is a StackOverflow article ( > >> https://stackoverflow.com/a/2183140/1426535) stating that it is > >> technically perfectly okay and also RFC 5280 says "These characters > >> [underscore and at-sign] often appear in Internet addresses. Such > >> addresses MUST be encoded using an ASN.1 type that supports them." > >> > > > > There's definitely been a lot of back and forth on this topic. It's > unclear > > if you're looking for a clearer statement about why they're forbidden or > > where they're forbidden. > > > > It is clear that Rufus is looking for a link to the deprecation ballot, > rather than the old (failed) non-deprecation ballot. > Thanks for sharing your interpretation. I don't think that is an accurate summary, but it's useful to understand your perspective and how you interpret things. > > If the question is where they are forbidden, > > https://tools.ietf.org/html/rfc5280#section-4.2.1.6 > > > > When the subjectAltName extension contains a domain name system > >> label, the domain name MUST be stored in the dNSName (an IA5String). > >> The name MUST be in the "preferred name syntax", as specified by > >> Section 3.5 of [RFC1034] and as modified by Section 2.1 of > >> [RFC1123]. Note that while uppercase and lowercase letters are > >> allowed in domain names, no significance is attached to the case. > In > >> addition, while the string " " is a legal domain name, > subjectAltName > >> extensions with a dNSName of " " MUST NOT be used. Finally, the use > >> of the DNS representation for Internet mail addresses > >> (subscriber.example.com instead of subscri...@example.com) MUST NOT > >> be used; such identities are to be encoded as rfc822Name. Rules for > >> encoding internationalized domain names are specified in Section > 7.2. > > > > The huge mess comes from the fact that this requirement of not > using the underscore character (which is actually used in some > RFC-specified DNS names labels, though for special purposes) was > buried in a complicated reference to two old RFCs, each of which > in turn describe that particular restriction in a complicated and > indirect way. > I find your summary interesting. I presume, then, that you feel that the need to use DNS is buried in complicated references to old RFCs, much as it would be how HTTP works or, for that matter, how ASN.1 works. It's certainly true that, as we build complex systems, we stand on the shoulder of giants, and as we build code and systems, we layer them. I think it's rather misguided and ignorant to suggest that, because a document is referenced by another document, it somehow becomes complicated, or that the age matters. Were that the case, we'd presume the Baseline Requirements would include everything from the IP specification to the ASN.1 specification, and everything in between, and then lament at how anyone is supposed to understand or maintain the salient bits of this 10,000 page document. Furthermore, Section 4.2.1.6 of RFC5280 applies only to > SubjectAltNames, not to DNS names placed directly in the Subject > Distinguished Name in the certificate. Thus this particular > restriction on DNS names to which certificates can be issued only > became effective as a side effect of deprecating TLS certificates > without SubjectAltNames. > If you're speaking to this side-effect being placed in 20 years ago, yes, sure, then it's a side-effect, and the industry has had nearly twenty years to contemplate the implications. The use of commonName within the context of TLS was very much a 'hack', emerging both from the lack of X.509v3 (and it's generic extension mechanism) and a repurposing of an existing OID in the absence of the X.500 Global DIT (with would have otherwise set the formatting restrictions). But it is inaccurate and revisionist to suggest that this was a restriction on DNS names expressed through certificates - as the underlying restriction itself comes from the host name form. That is, 5280 is restating existing policy, not introducing new policy, in the hope that people would understand, rather than entrench deeper into their misunderstanding. This made it completely unclear to most people that DNS labels > with underscores were not
Re: CA Communication: Underscores in dNSNames
On 10/12/2018 18:09, Ryan Sleevi wrote: > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Hello! >> >> It would be helpful, if the CA/B or Mozilla could publish a document on >> its web pages to which we can redirect our customers, if they have >> technical questions about this underscore issue. Right now, I can only tell >> them, that they are forbidden because the ballot to explicitly allow them >> failed, but not really why. Especially since the first result in Google for >> "underscore domain name" is a StackOverflow article ( >> https://stackoverflow.com/a/2183140/1426535) stating that it is >> technically perfectly okay and also RFC 5280 says "These characters >> [underscore and at-sign] often appear in Internet addresses. Such >> addresses MUST be encoded using an ASN.1 type that supports them." >> > > There's definitely been a lot of back and forth on this topic. It's unclear > if you're looking for a clearer statement about why they're forbidden or > where they're forbidden. > It is clear that Rufus is looking for a link to the deprecation ballot, rather than the old (failed) non-deprecation ballot. > If the question is where they are forbidden, > https://tools.ietf.org/html/rfc5280#section-4.2.1.6 > > When the subjectAltName extension contains a domain name system >> label, the domain name MUST be stored in the dNSName (an IA5String). >> The name MUST be in the "preferred name syntax", as specified by >> Section 3.5 of [RFC1034] and as modified by Section 2.1 of >> [RFC1123]. Note that while uppercase and lowercase letters are >> allowed in domain names, no significance is attached to the case. In >> addition, while the string " " is a legal domain name, subjectAltName >> extensions with a dNSName of " " MUST NOT be used. Finally, the use >> of the DNS representation for Internet mail addresses >> (subscriber.example.com instead of subscri...@example.com) MUST NOT >> be used; such identities are to be encoded as rfc822Name. Rules for >> encoding internationalized domain names are specified in Section 7.2. > The huge mess comes from the fact that this requirement of not using the underscore character (which is actually used in some RFC-specified DNS names labels, though for special purposes) was buried in a complicated reference to two old RFCs, each of which in turn describe that particular restriction in a complicated and indirect way. Furthermore, Section 4.2.1.6 of RFC5280 applies only to SubjectAltNames, not to DNS names placed directly in the Subject Distinguished Name in the certificate. Thus this particular restriction on DNS names to which certificates can be issued only became effective as a side effect of deprecating TLS certificates without SubjectAltNames. This made it completely unclear to most people that DNS labels with underscores were not permitted in certificates. Thus the restriction was not widely known outside the CA/root program discussion groups until the rapid sunset was announced in November. > > If the question is "why", then the answer is "Because the preferred name > syntax forbids them" > If the question is "Why does the preferred name syntax forbid them", that > is answered in RFC 1035, Section 2.3.1 > > https://tools.ietf.org/html/rfc1035#section-2.3.1 > >> The DNS specifications attempt to be as general as possible in the rules >> for constructing domain names. The idea is that the name of any >> existing object can be expressed as a domain name with minimal changes. > > > > However, when assigning a domain name for an object, the prudent user >> will select a name which satisfies both the rules of the domain system >> and any existing rules for the object, whether these rules are published >> or implied by existing programs. > > > > For example, when naming a mail domain, the user should satisfy both the >> rules of this memo and those in RFC-822. When creating a new host name, >> the old rules for HOSTS.TXT should be followed. This avoids problems >> when old software is converted to use domain names. > > > > [ABNF omitted here] > > Note that this ABNF is one of only two places expressing the restriction that is now being vigorously enforced 30 years later. And that ABNF isn't even applicable due to RFC1123. > > Note that while upper and lower case letters are allowed in domain >> names, no significance is attached to the case. That is, two names with >> the same spelling but different case are to be treated as if identical. > > > > The labels must follow the rules for ARPANET host names. They must >> start with a letter, end with a letter or digit, and have as interior >> characters only letters, digits, and hyphen. There are also some >> restrictions on the length. Labels must be 63 characters or less. > And this paragraph is the second place, which is also not entirely
Re: CA Communication: Underscores in dNSNames
On Sat, Dec 8, 2018 at 12:50 PM pilgrim2223--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > thanks for the suggestions. > > We are exploring the OCSP and CRL checks. It has potential. > > Have you determined if these applications perform revocations checks, or if those checks can be blocked? > > As to getting certs from a different root, that wouldn't help us. We have > no Technical reason to keep underscored certs and are happy to get rid of > them, it is simply the effort required and the timeline given that are an > issue. > > ___ 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
On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello! > > It would be helpful, if the CA/B or Mozilla could publish a document on > its web pages to which we can redirect our customers, if they have > technical questions about this underscore issue. Right now, I can only tell > them, that they are forbidden because the ballot to explicitly allow them > failed, but not really why. Especially since the first result in Google for > "underscore domain name" is a StackOverflow article ( > https://stackoverflow.com/a/2183140/1426535) stating that it is > technically perfectly okay and also RFC 5280 says "These characters > [underscore and at-sign] often appear in Internet addresses. Such > addresses MUST be encoded using an ASN.1 type that supports them." > There's definitely been a lot of back and forth on this topic. It's unclear if you're looking for a clearer statement about why they're forbidden or where they're forbidden. If the question is where they are forbidden, https://tools.ietf.org/html/rfc5280#section-4.2.1.6 When the subjectAltName extension contains a domain name system >label, the domain name MUST be stored in the dNSName (an IA5String). >The name MUST be in the "preferred name syntax", as specified by >Section 3.5 of [RFC1034] and as modified by Section 2.1 of >[RFC1123]. Note that while uppercase and lowercase letters are >allowed in domain names, no significance is attached to the case. In >addition, while the string " " is a legal domain name, subjectAltName >extensions with a dNSName of " " MUST NOT be used. Finally, the use >of the DNS representation for Internet mail addresses >(subscriber.example.com instead of subscri...@example.com) MUST NOT >be used; such identities are to be encoded as rfc822Name. Rules for >encoding internationalized domain names are specified in Section 7.2. If the question is "why", then the answer is "Because the preferred name syntax forbids them" If the question is "Why does the preferred name syntax forbid them", that is answered in RFC 1035, Section 2.3.1 https://tools.ietf.org/html/rfc1035#section-2.3.1 > The DNS specifications attempt to be as general as possible in the rules > for constructing domain names. The idea is that the name of any > existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user > will select a name which satisfies both the rules of the domain system > and any existing rules for the object, whether these rules are published > or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the > rules of this memo and those in RFC-822. When creating a new host name, > the old rules for HOSTS.TXT should be followed. This avoids problems > when old software is converted to use domain names. [ABNF omitted here] Note that while upper and lower case letters are allowed in domain > names, no significance is attached to the case. That is, two names with > the same spelling but different case are to be treated as if identical. The labels must follow the rules for ARPANET host names. They must > start with a letter, end with a letter or digit, and have as interior > characters only letters, digits, and hyphen. There are also some > restrictions on the length. Labels must be 63 characters or less. That is, the choice for how host names are expressed (A/, for example) are derived from the syntax restrictions from HOSTS.TXT, which traces through to the rules of ARPANET host names. The answer for "Why" is thus "To ensure backwards compatibility with existing applications, and ensure an unambiguous representation". What I mean by "unambiguous" is, for example, the discussion about case sensitivity. A DNS label is 8-byte clean, but a hostname uses the LDH rule. If Client A interpreted "eXaMpLe.CoM" differently than Client B did - for example, Client A used the existing HOSTS.TXT/ARPANET syntax and got one host, while Client B used a case-sensitive algorithm - you could end up with client confusion and incompatibility. This isn't theoretical either - the IDNA 2003/2008/transitional issues have shown real confusion that can arise with competing encodings. You can find more about the terminology in https://tools.ietf.org/html/rfc7719 if you want, but hopefully that clarifies the "Why" - it has **always** been forbidden, just like it has * *always** been forbidden to encode email addresses in DNS, and instead require they use the RFC 822 syntax. ___ 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
On Monday, November 12, 2018 at 3:19:17 PM UTC-8, Wayne Thayer 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
Re: CA Communication: Underscores in dNSNames
thanks for the suggestions. We are exploring the OCSP and CRL checks. It has potential. As to getting certs from a different root, that wouldn't help us. We have no Technical reason to keep underscored certs and are happy to get rid of them, it is simply the effort required and the timeline given that are an issue. ___ 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
On Sat, Dec 8, 2018 at 5:01 AM Richard Moore via dev-security-policy wrote: > > > the scope of the main project if ~120 certs across a similar number of > > vendors. One of the home grown applications also hardcode the name of the > > certificate into the application and will require not only certificate > > update in coordination with the vendors but code changes on 120 certs in 12 > > days. > > It seems likely to me that these applications won't actually support OCSP and > updating any CRLs in use may well be a manual process too. So, if the > certificates were revoked, would your applications actually notice at all? > It's quite different from them expiring which is coded into the certificate > itself. Even if these apps support revocation checking, their root stores might contain one or more ancient roots that are no longer needed by any WebPKI certificate, and could therefore be removed from BR scope and continue issuing underscore-containing certificates. When SHA1 was deprecated, Sectigo (née Comodo) requested root stores remove one of their roots [1], taking it out of scope for the BRs, and continued issuing "legacy" SHA1 certificates off of that root. Sectigo has also published a list of certificates containing underscores they will be revoking [2]; conspicuously absent from that list are four of these legacy SHA1 certificates [3]. Perhaps pilgrim's company (Verizon?) could convince a CA to do something similar here? Best, Alex [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1208461 [2]: https://misissued.com/batch/41/ [3]: https://crt.sh/?id=701056092, https://crt.sh/?id=700688392, https://crt.sh/?id=701055930, https://crt.sh/?id=700688392 ___ 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
> the scope of the main project if ~120 certs across a similar number of > vendors. One of the home grown applications also hardcode the name of the > certificate into the application and will require not only certificate update > in coordination with the vendors but code changes on 120 certs in 12 days. It seems likely to me that these applications won't actually support OCSP and updating any CRLs in use may well be a manual process too. So, if the certificates were revoked, would your applications actually notice at all? It's quite different from them expiring which is coded into the certificate itself. Kind Regards Rich ___ 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
On Fri, Dec 07, 2018 at 08:13:24AM -0800, pilgrim2223--- via dev-security-policy wrote: > As a retail organization we are in a moratorium till 1/2/2019 this happens > every year. So nothing is being done that may jeopardize selling of > widgets! Choosing to not do something is, itself, doing something. > The project owners claim that timeline is impossible, and deploying 30 day > validity certs is a similar level of effort without the code changes, and > even that may not be possible. By a strict reading of the BRs, these missued certificates should have been revoked within, at most, five days. If future problems are identified, that may happen. So I suggest you talk to your project owners, apprise them of the situation, and take steps to allow your systems to be able to react in line with this potential timeline. > To be perfectly clear here. We are 100% on board with a depreciation of > the underscore (once we learned there was and issue with them from our CA > we started restricting their issuance) This is not a change in the rules (the BRs have always forbidden this type of issuance), nor is it even a change in external circumstance (new research results showing something that was thought to be safe wasn't). Your CA sold you something they shouldn't have, and which they should have known they shouldn't have. If you're unhappy with what your CA sold you, I would recommend discussing the problem with them, perhaps with the assistance of your legal team. > now, and does not pose a security vulnerability. I assume you've got something to back up that statement, beyond "I can't think of any way this could be a security vulnerability". There are more implementations in heaven and earth than are dreamt of in your philosophy, and all that. - Matt ___ 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
Fair enough Impact is this: As a retail organization we are in a moratorium till 1/2/2019 this happens every year. So nothing is being done that may jeopardize selling of widgets! A process was put in place for 2wayssl where we'd name the cert based on what it does (so 2wayssl_to_from.domain.com) which we would then use for our own and partner vendor applications. the scope of the main project if ~120 certs across a similar number of vendors. One of the home grown applications also hardcode the name of the certificate into the application and will require not only certificate update in coordination with the vendors but code changes on 120 certs in 12 days. The project owners claim that timeline is impossible, and deploying 30 day validity certs is a similar level of effort without the code changes, and even that may not be possible. This particular application is how we link with our partners for activation and generates ~2b per year in revenue. To be perfectly clear here. We are 100% on board with a depreciation of the underscore (once we learned there was and issue with them from our CA we started restricting their issuance) The issue is I tell application owners this needs to be done, they want to know why they aren't even getting the 90 days they'd get if these were depreciated less aggressively (same they had for SHA1) for something that has not been a problem till now, and does not pose a security vulnerability. As it sits from CA alerting us to the final outcome we got 44 days, 31 of which are over a holiday moratorium. So for full scope: 260 certs out of compliance in my enterprise (out of ~17,000 current valid certs) Of those 120 are problematic to replace in time, but could easily be done by the end of Q1 If I could get browser blessing to give us at least Q1 to finish this it would make the entire world a much better place for me :) On Friday, December 7, 2018 at 8:39:15 AM UTC-7, Jeremy Rowley wrote: > Personally, i think you should continue the discussion here. Although you can > bring it up to whichever ca you use, the reality is that without the browsers > knowing why the certs cant be replaced and the number, theres no way to gauge > their reaction to a non compliance. The penalties may include root removal > (see symantec) so I doubt many cas would be willing to risk a qualification > without clear guidance from the browsers on the risk associated with the non > compliance. > > From: dev-security-policy on > behalf of pilgrim2223--- via dev-security-policy > > Sent: Friday, December 7, 2018 8:26:42 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: CA Communication: Underscores in dNSNames > > Thank you very much for your response! > > So at the end of the day I will not get any relief from the browsers, and > will need to get an exception from my CA? > > When I asked the CA they told me to take it here. Feels like the CA is where > I'm going to have to focus! > > Thanks again for your time! > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUtno=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5MQa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQDJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILSXzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZEMPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy ___ 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
On Fri, Dec 7, 2018 at 4:35 PM Jeremy Rowley wrote: > I only ask because telling people to go back to the CA and work something > out isn’t a great answer when the retort is that the CA will be distrusted > if they don’t. Either the customer doesn’t replace all their certs and they > are made non-functional by revocation or the certs are distrusted because > the CA isn’t operational anymore. Telling people to go have the CA cover > the risk when those are the two options seems like we’re avoiding the > public discussion. > Why not? It's fundamentally the CA taking the risk on when deciding whether or not to meet the requirements of the programs that they participate in - whether technical, policy, or contractual. If a customer wanted to ask a CA to break a contractual requirement, isn't it ultimately the CA they should be asking? I think we're in agreement that, regardless, the CA MUST receive a qualified audit. There's seemingly no defense that if they fail to revoke, it should be a qualification, and there's even an argument that the issuance itself should have been a qualification (and result in their auditor re-evaluating these material facts, such as under AT-C 205.A54-A57 regarding revisions to opinions in light of subsequent events and application guidance). It's unclear what you expect to result from a public discussion, so perhaps it would be helpful if you could clarify. It sounds like you're looking for a blanket rubric for which to ignore the requirements of the Baseline Requirements, so that the rubric can then be applied customer requests, and determine whether or not these individual customers justify violating the BRs. A good CA would acknowledge the rubric is, in fact, zero - zero violations is the "justified" case, and everything else is the risk case. Alternatively, it may be a desire that a rubric should exist, a priori to any violations, so as to help determine whether a violation is justified, even when the stated goal is zero violations. If you look at public discussions, think about what the goals are of the Incident Response template, which is about understanding how the CA's processes failed. If you were to imagine intentionally violating the BRs, knowingly, it seems like an incident response template would be far more damning for that CA's operational competencies. That's not to suggest to CAs its better to ask forgiveness than permission - a CA that ignored changes in the BRs, clearly communicated (as Wayne mentioned in the original post), also seems likely to have an incident report template that is quite damning. Using the experiences from the SHA-1 exception process, the only formalized exception process, you can see that even in those limited cases, there was significant skepticism towards the reasons. I would think that any proposal for exceptions minimally achieve that degree of transparency, but would be equally damning if those justifications were the same as those used for SHA-1 - as the SHA-1 exception process "should" have revealed that those are not, in fact, seen as legitimate. If it helps to imagine this as a "How would this incident be received if it became part of a Wiki page that listed a series of ongoing violations", I think any CA contemplating not meeting the required transition date should be asking "How many issues have I (or my sub-CAs) had under https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ). And there are definitely some CAs that do not look to great in that light. ___ 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
I only ask because telling people to go back to the CA and work something out isn’t a great answer when the retort is that the CA will be distrusted if they don’t. Either the customer doesn’t replace all their certs and they are made non-functional by revocation or the certs are distrusted because the CA isn’t operational anymore. Telling people to go have the CA cover the risk when those are the two options seems like we’re avoiding the public discussion. From: Ryan Sleevi Sent: Friday, December 7, 2018 2:26 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: CA Communication: Underscores in dNSNames On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: This isn't a CA-issue because the risk associated with non-compliance isn't defined yet. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ ""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason. This may happen immediately or on a planned future date. Mozilla will disable or remove a certificate if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of this policy."" Sounds like the risk is well-defined and documented. >From what I've heard here, the risk is distrust or loss of EV indicators, which is distrust-like. That's a pretty big thing to push back on the CA for a non-security issue. Thus, I think the risk of missing the underscore revocation date needs to be discussed here so everyone, including website operators and the relying parties, know first-hand what the risks of the CA missing the deadline are. Any and every qualification or failure to abide by the program requirements comes with it the risk of sanction, up to, and including, distrust. It sounds like you're looking for a way for CAs to make a cost/benefit analysis as to whether it's more beneficial to them to violate requirements, by having a clearer guarantee what it will cost them if they intentionally do so, versus what they may gain from their Subscribers. That doesn't really seem aligned with the incentives of the ecosystem or the relying parties, since CAs (and their Subscribers) are not able to, on purely technical level, evaluate the cost or impact to Relying Parties, since Relying Parties include every possible entity that trusts that root. If the risk is that there is a note on the audit, that is an acceptable risk. If the risk is a loss of the root...probably less so. Pushing the question back to the CA without better discussion by the browsers makes finding a solution or understanding the risks impossible. While I think it's positive and encouraging to see CAs acknowledge that their audits exist to disclose non-conformities/qualifications, I don't think it should be seen as legitimizing or accepting that intentional non-conformities/qualifications are desirable. A well-run CA should strive to have zero qualifications, findings, or non-conformities - not because they were able to convince their auditor that they weren't issues / were minor, but because they operated above and beyond reproach, and there were literally no issues. Anything short of that is an indicator that a CA is failing in its role as a trusted steward, and repeated failures seem reasonable to discuss sanction or distrust. CAs (and their sub-CAs) with a pattern of incidents on the incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk of sanction, given the pre-existing patterns of non-compliance. 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: CA Communication: Underscores in dNSNames
That’s not well defined as there are various grades below that. Is the plan to remove any CA that doesn’t comply with this requirement? From: Ryan Sleevi Sent: Friday, December 7, 2018 2:26 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: CA Communication: Underscores in dNSNames On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: This isn't a CA-issue because the risk associated with non-compliance isn't defined yet. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ ""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason. This may happen immediately or on a planned future date. Mozilla will disable or remove a certificate if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of this policy."" Sounds like the risk is well-defined and documented. >From what I've heard here, the risk is distrust or loss of EV indicators, which is distrust-like. That's a pretty big thing to push back on the CA for a non-security issue. Thus, I think the risk of missing the underscore revocation date needs to be discussed here so everyone, including website operators and the relying parties, know first-hand what the risks of the CA missing the deadline are. Any and every qualification or failure to abide by the program requirements comes with it the risk of sanction, up to, and including, distrust. It sounds like you're looking for a way for CAs to make a cost/benefit analysis as to whether it's more beneficial to them to violate requirements, by having a clearer guarantee what it will cost them if they intentionally do so, versus what they may gain from their Subscribers. That doesn't really seem aligned with the incentives of the ecosystem or the relying parties, since CAs (and their Subscribers) are not able to, on purely technical level, evaluate the cost or impact to Relying Parties, since Relying Parties include every possible entity that trusts that root. If the risk is that there is a note on the audit, that is an acceptable risk. If the risk is a loss of the root...probably less so. Pushing the question back to the CA without better discussion by the browsers makes finding a solution or understanding the risks impossible. While I think it's positive and encouraging to see CAs acknowledge that their audits exist to disclose non-conformities/qualifications, I don't think it should be seen as legitimizing or accepting that intentional non-conformities/qualifications are desirable. A well-run CA should strive to have zero qualifications, findings, or non-conformities - not because they were able to convince their auditor that they weren't issues / were minor, but because they operated above and beyond reproach, and there were literally no issues. Anything short of that is an indicator that a CA is failing in its role as a trusted steward, and repeated failures seem reasonable to discuss sanction or distrust. CAs (and their sub-CAs) with a pattern of incidents on the incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk of sanction, given the pre-existing patterns of non-compliance. 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: CA Communication: Underscores in dNSNames
On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This isn't a CA-issue because the risk associated with non-compliance isn't > defined yet. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ ""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason. This may happen immediately or on a planned future date. Mozilla will disable or remove a certificate if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of this policy."" Sounds like the risk is well-defined and documented. > From what I've heard here, the risk is distrust or loss of EV > indicators, which is distrust-like. That's a pretty big thing to push back > on the CA for a non-security issue. Thus, I think the risk of missing the > underscore revocation date needs to be discussed here so everyone, > including > website operators and the relying parties, know first-hand what the risks > of > the CA missing the deadline are. Any and every qualification or failure to abide by the program requirements comes with it the risk of sanction, up to, and including, distrust. It sounds like you're looking for a way for CAs to make a cost/benefit analysis as to whether it's more beneficial to them to violate requirements, by having a clearer guarantee what it will cost them if they intentionally do so, versus what they may gain from their Subscribers. That doesn't really seem aligned with the incentives of the ecosystem or the relying parties, since CAs (and their Subscribers) are not able to, on purely technical level, evaluate the cost or impact to Relying Parties, since Relying Parties include every possible entity that trusts that root. > If the risk is that there is a note on the > audit, that is an acceptable risk. If the risk is a loss of the > root...probably less so. Pushing the question back to the CA without > better > discussion by the browsers makes finding a solution or understanding the > risks impossible. While I think it's positive and encouraging to see CAs acknowledge that their audits exist to disclose non-conformities/qualifications, I don't think it should be seen as legitimizing or accepting that intentional non-conformities/qualifications are desirable. A well-run CA should strive to have zero qualifications, findings, or non-conformities - not because they were able to convince their auditor that they weren't issues / were minor, but because they operated above and beyond reproach, and there were literally no issues. Anything short of that is an indicator that a CA is failing in its role as a trusted steward, and repeated failures seem reasonable to discuss sanction or distrust. CAs (and their sub-CAs) with a pattern of incidents on the incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk of sanction, given the pre-existing patterns of non-compliance. ___ 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
Personally, i think you should continue the discussion here. Although you can bring it up to whichever ca you use, the reality is that without the browsers knowing why the certs cant be replaced and the number, theres no way to gauge their reaction to a non compliance. The penalties may include root removal (see symantec) so I doubt many cas would be willing to risk a qualification without clear guidance from the browsers on the risk associated with the non compliance. From: dev-security-policy on behalf of pilgrim2223--- via dev-security-policy Sent: Friday, December 7, 2018 8:26:42 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Communication: Underscores in dNSNames Thank you very much for your response! So at the end of the day I will not get any relief from the browsers, and will need to get an exception from my CA? When I asked the CA they told me to take it here. Feels like the CA is where I'm going to have to focus! Thanks again for your time! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUtno=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5MQa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQDJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILSXzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZEMPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy ___ 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
Thank you very much for your response! So at the end of the day I will not get any relief from the browsers, and will need to get an exception from my CA? When I asked the CA they told me to take it here. Feels like the CA is where I'm going to have to focus! Thanks again for your time! ___ 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
On Thu, Dec 6, 2018 at 10:36 PM pilgrim2223--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I need some clarification on something here
>
> 1) Why are legacy certs not being allowed to expire, and instead we are
> being forced to replace in a very short window? We stopped issuing certs
> with underscores as soon as our CA told us to (probably mid-September) but
> that still puts me at having hundreds of certs needing remediation in a
> period where retail production systems are not allowed to be touched.
>
> Experience with past sunsets (e.g. sha-1) has proven that allowing
certificates to naturally expire results in a bad outcome - Subscribers are
somehow unaware of the sunset until their certificate is about to expire,
at which point they can't get a replacement certificate and don't have time
to fix their systems. The revocation requirement ensures that Subscribers
are aware of the sunset while the provision for continued issuance of
30-day duration certificates provides additional time to update systems.
The short window is the result of a compromise with certain CAs and
browsers that argued for no sunset period at all because underscores have
never been permitted in BR-compliant certificates. That conclusion would
in-turn trigger the 5-day revocation requirement from section 4.9.1.1 of
the BRs.
2) If a certificate is not used to host a URL (say for server to server
> communication or 2way SSL... what does it matter, and can we allow those to
> remain till natural expiration?
>
> This sounds like a case where a publicly-trusted TLS server certificate is
being used for something other than the intended purpose. Unfortunately,
doing that carries the risk that those certificates will need to adapt to
[sometime rapid] changes to the requirements for TLS server certificates.
This also happened with the sha-1 sunset and is a good example of why it's
not a good idea to use publicly-trusted TLS server certificates for other
purposes.
3) Is there any exception process available that will allow us to keep our
> existing certs through their validity?
>
> There is no process for granting an exception to the BRs without the
consequence of a potential audit finding for the CA. It's up to the CA to
determine if they want to take the risk of an audit finding. It would
likely help to quantify the problem in terms of how many certificates, how
much extra time would be required to replace them, what steps are being
taken to expedite replacement, and what the risk/consequences are of having
these certificates revoked prior to replacement.
Thank you
>
> On Monday, November 12, 2018 at 4:19:17 PM UTC-7, Wayne Thayer 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
Re: CA Communication: Underscores in dNSNames
I need some clarification on something here
1) Why are legacy certs not being allowed to expire, and instead we are being
forced to replace in a very short window? We stopped issuing certs with
underscores as soon as our CA told us to (probably mid-September) but that
still puts me at having hundreds of certs needing remediation in a period where
retail production systems are not allowed to be touched.
2) If a certificate is not used to host a URL (say for server to server
communication or 2way SSL... what does it matter, and can we allow those to
remain till natural expiration?
3) Is there any exception process available that will allow us to keep our
existing certs through their validity?
Thank you
On Monday, November 12, 2018 at 4:19:17 PM UTC-7, Wayne Thayer 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
Re: CA Communication: Underscores in dNSNames
Wayne, many thanks for drawing the attention of the CAs to this matter.
Sectigo (formerly Comodo CA) stopped issuing certificates with
underscores in dNSNames soon after CABForum ballot 202 failed. A search
of our CA database this week found 251 certificates that are in scope
for the BRs, expire on or after 15th January 2019, and that have at
least one underscore in a dNSName.
To track Sectigo's progress towards the 15th January 2019 revocation
deadline, I've created a new batch on Alex Gaynor's excellent Revocation
Tracker:
https://misissued.com/batch/41/
On 12/11/2018 23:18, 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
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
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
I agree with Tim on the interpretation and can confirm that my intent was as Tim described. Perhaps the confusion is over the purpose of the <30 day exception. It wasn't to exempt legacy certificates near the end of their lifetime from being revoked. It was to allow subscribers to begin using 30-day duration certificates prior to 15-January without having to replace them on the 15th. On Wed, Nov 14, 2018 at 4:20 PM Tim Shirley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Validity period is a defined term in the BRs and refers to the time > between issuance and expiry. Since the new language uses that term without > any modifiers like "remaining", it seems clear to me that both of those > example certificates would need to be revoked. > > From: dev-security-policy > on behalf of Bruce via dev-security-policy < > dev-security-policy@lists.mozilla.org> > Sent: Wednesday, November 14, 2018 5:37:20 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: CA Communication: Underscores in dNSNames > > Hi Wayne, I wanted to get some clarification. > > For example, let's say that a Subscriber has a 1 year certificate which > expires on 30 January 2019. On 15 January 2019, the remaining validity > period is less than 30 days; as such, I interpret that the certificate does > not have to be revoked. > > On the other hand, if the Subscriber has a 1 year certificate which > expires on 31 March 2019, then on 15 January 2019, the remaining validity > period is greater than 30 days, so this certificate must be revoked. > > Is the above interpretation correct? > > Thanks, Bruce. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > > https://scanmail.trustwave.com/?c=4062=qqPs2ylE2M0AE1hucuCDnbrKTL8yhgbe2AJ51iwegw=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-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: CA Communication: Underscores in dNSNames
Validity period is a defined term in the BRs and refers to the time between issuance and expiry. Since the new language uses that term without any modifiers like "remaining", it seems clear to me that both of those example certificates would need to be revoked. From: dev-security-policy on behalf of Bruce via dev-security-policy Sent: Wednesday, November 14, 2018 5:37:20 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Communication: Underscores in dNSNames Hi Wayne, I wanted to get some clarification. For example, let's say that a Subscriber has a 1 year certificate which expires on 30 January 2019. On 15 January 2019, the remaining validity period is less than 30 days; as such, I interpret that the certificate does not have to be revoked. On the other hand, if the Subscriber has a 1 year certificate which expires on 31 March 2019, then on 15 January 2019, the remaining validity period is greater than 30 days, so this certificate must be revoked. Is the above interpretation correct? Thanks, Bruce. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://scanmail.trustwave.com/?c=4062=qqPs2ylE2M0AE1hucuCDnbrKTL8yhgbe2AJ51iwegw=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy ___ 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
Hi Wayne, I wanted to get some clarification. For example, let's say that a Subscriber has a 1 year certificate which expires on 30 January 2019. On 15 January 2019, the remaining validity period is less than 30 days; as such, I interpret that the certificate does not have to be revoked. On the other hand, if the Subscriber has a 1 year certificate which expires on 31 March 2019, then on 15 January 2019, the remaining validity period is greater than 30 days, so this certificate must be revoked. Is the above interpretation correct? Thanks, Bruce. ___ 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
On Wed, Nov 14, 2018 at 9:47 AM Vincent Lynch wrote:
> Was looking for some quick clarification on interpretation of this bit:
>
> *"All certificates containing an underscore character in any dNSName entry
> and having a validity period of more than 30 days MUST be revoked prior to
> January 15, 2019."*
>
> This language refers to the TOTAL validity period of the certificate, not
> the REMAINING validity, correct?
>
> Correct.
So, for example, a certificate with a NotBefore: 2/1/18 and NotAfter:
> 1/30/19 would have to be revoked?
>
Yes.
Only certificates with a TOTAL validity of <30 days (example, NotBefore:
> 12/20/18, NotAfter: 1/19/19) would be allowed to naturally expire?
>
> Yes. The thinking here is that many organizations don't pay attention to
certificate sunsets (e.g. sha-1) until it affects them directly. By
requiring them to replace their certificates while still allowing some time
to transition away from them via 30-day duration certificates, the hope is
that we will avoid the urgent calls for exceptions we've seen with past
sunset periods.
Thanks,
>
> Vincent
>
> On Mon, Nov 12, 2018 at 4:19 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> 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
>>
>
>
> --
> Vincent Lynch
>
___
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
Was looking for some quick clarification on interpretation of this bit:
*"All certificates containing an underscore character in any dNSName entry
and having a validity period of more than 30 days MUST be revoked prior to
January 15, 2019."*
This language refers to the TOTAL validity period of the certificate, not
the REMAINING validity, correct?
So, for example, a certificate with a NotBefore: 2/1/18 and NotAfter:
1/30/19 would have to be revoked?
Only certificate swith a TOTAL validity of <30 days (example, NotBefore:
12/20/18, NotAfter: 1/19/19) would be allowed to naturally expire?
Thanks,
Vincent
On Mon, Nov 12, 2018 at 4:19 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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
>
--
Vincent Lynch
___
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
It was pointed out that the email I sent to CAs stated that the effective
date of the ballot (once it completed the IPR review period) will be
December 10, **2019**. The year is obviously wrong and contradicts the rest
of the message. The correct effective date is December 10, **2018**. All of
the relevant compliance dates in the email are correct, so I'm not planning
to resend the CA communication.
- Wayne
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
Re: CA Communication: Underscores in dNSNames
On Mon, Nov 12, 2018 at 6:18 PM Man Ho via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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?
>
> No, this does not mean that the CA needs to perform domain validation on
the FQDN with underscores replaced by hyphens. It means that underscores
are only permitted in certain positions within the domain label, as
discussed in the lead-up to ballot 202 (this language is copied directly
from ballot 202). For example:
https://cabforum.org/pipermail/public/2017-May/011186.html
Secondly, is it necessary for CAs to state their practice of handling
> underscore domain name in CPS?
>
> No, that is not a Mozilla requirement.
- 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
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
