Re: DigiCert BR violation

On 13/03/17 21:31, Jeremy Rowley wrote: > [JR] If you recall, I did try to change the policy. I was told to > change the RFC if I didn’t like the requirement. I find trying to > change the RFC nearly impossible as PKIX is dead and there are too > many other issues people would also like to

Re: DigiCert BR violation

On 2017-03-14 02:19, Peter Bowen wrote: On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy wrote: On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote: Are you saying that there are one or more clients that require DigiCert to

Re: DigiCert BR violation

On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy wrote: > On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote: >> Are you saying that there are one or more clients that require DigiCert to >> support Teletext strings? > > Can we stop

Re: DigiCert BR violation

On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote: > Are you saying that there are one or more clients that require DigiCert to > support Teletext strings? Can we stop saying Teletext? The X500 series standards are talking about Teletex. One letter shorter. Teletext was invented by the

RE: DigiCert BR violation

Sent: Monday, March 13, 2017 3:32 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert BR violation On Monday, March 13, 2017 at 5:12:39 PM UTC-4, Jeremy Rowley wrote: > I don't disagree that teletext shouldn't be used, and we no longer > include it in new certi

RE: DigiCert BR violation

Although we have a policy against using live certificates for testing, the policy was not followed in this case. Can you share why? Can you share what steps you'll be taking to make sure policies are followed in the future? I think we've seen some pretty stark examples about what can happen

Re: DigiCert BR violation

On Monday, March 13, 2017 at 5:12:39 PM UTC-4, Jeremy Rowley wrote: > I don't disagree that teletext shouldn't be used, and we no longer include > it in new certificate requests or renewals. However, we do include teletext > in certificates that originally had teletext strings but are being

Re: DigiCert BR violation

On Thu, Mar 09, 2017 at 06:29:57PM -0500, Ryan Sleevi via dev-security-policy wrote: > > However, I think this discussion raises some very interesting points about > > real world scenarios and RFC 5280 that should be addressed. DigiCert > > actually has three items that routinely show up on

Re: DigiCert BR violation

(Wearing an individual hat) On Thu, Mar 9, 2017 at 4:18 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Although we have a policy > against using live certificates for testing, the policy was not followed in > this case. Can you share why? Can you

RE: DigiCert BR violation

-pol...@lists.mozilla.org Subject: DigiCert BR violation It appears that DigiCert has violated the Baseline Requirements, as recently notified to the CA/Browser Forum. The certificate at https://crt.sh/?id=98120546 does not comply with RFC 5280. RFC 5280 defines the upper-bound of the commonName

Re: DigiCert BR violation

On 2017-03-09 02:08, Ryan Sleevi wrote: It appears that DigiCert has violated the Baseline Requirements, as recently notified to the CA/Browser Forum. The certificate at https://crt.sh/?id=98120546 does not comply with RFC 5280. RFC 5280 defines the upper-bound of the commonName field as 64

DigiCert BR violation

It appears that DigiCert has violated the Baseline Requirements, as recently notified to the CA/Browser Forum. The certificate at https://crt.sh/?id=98120546 does not comply with RFC 5280. RFC 5280 defines the upper-bound of the commonName field as 64 characters, specifically ub-common-name