The ballot on this started today
> On Sep 1, 2016, at 7:21 AM, Kurt Roeckx <k...@roeckx.be> wrote: > >> On 2016-09-01 14:21, Matt Palmer wrote: >>> On Thu, Sep 01, 2016 at 10:53:36AM +0300, Eddy Nigg wrote: >>>> On 09/01/2016 04:20 AM, Matt Palmer wrote: >>>> You were knowingly violating a MUST provision of RFC5280. >>> >>> From experience there have been many RFC violations, sometimes even >>> knowingly and intentionally by software vendors (browsers), certificate >>> authorities and even policy writers such as CAB Forum. >> >> "They did it too" is not a persuasive argument coming from my >> four-year-olds. It is no more persuasive coming from a Certification >> Authority. >> >> In the interests of the community being fully informed of StartCom's >> compliance with the standards which underlie the integrity of the web PKI, >> I'll ask the question again: what *other* MUST provisions of RFC5280, the >> CA/B Forum BRs, and other relevant specifications and guidance relevant to >> the operation of a Certification Authority present in the Mozilla trust >> store, is StartCom currently not in compliance with? Have your auditors >> proactively been made aware of these deficiencies? > > I can actually give an example of that. If the certificate is > individual-validated, they have a givenName, surname, localityName and > stateOrProvinceName, but no organizationName. This is actually a violation > of the BR requirements. The BR requirements says that it should either also > have an organizationName, or the localityName and stateOrProvinceName should > be removed. So one option is to replace the givenName and surname by an > organizationName. But I think this is just a case where the BRs are wrong > and should get fixed. There has at least been some discussion about that, > but the change still isn't approved. > > > Kurt > > _______________________________________________ > 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
