On Thu, Dec 6, 2018 at 10:36 PM pilgrim2223--- via dev-security-policy <
[email protected]> 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
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
