On Thu, Sep 25, 2014 at 03:06:59PM +0200, Certificates wrote: > Answers for Matt Palmer questions: > > On Wed, Sep 24, 2014 at 05:17:02AM -0700, [email protected] wrote: > > As you can see above in the same point of CPS: > > > > "To receive a certificate it is necessary for the subscriber who is a > natural person or an authorised > > representative of the recipient of certification services to present: > > 1) an identification card (or its photocopy depending on the type of > certificate); > > 2) documents confirming rights to the domain (optionally, relative to > the certificate type); > > 3) a file with the certificate request (if the pair of keys is generated > individually by the subscriber)." > > > > In case of test certificates according our CPS we can skip point 1 from > > the above list. It means that we do not force subscriber to visit our > RA > > and show his identification card, as we do in case of another kinds of > > certificates. But still all other things like agreement, order and > > documents confirming rights to the domain are verified carefully. > > Rights to the domain is indicated there as being "optional", and I can't > find any indication in the CPS of which certificate types will be > domain-validated. Also, the only place I've found a description of your > domain validation practices is at the bottom of CPS s3.2.2, which only > mentions having information placed on a server. My reading of the e-mail > communication option is for purposes other than domain validation. Can > you > confirm that is the case? > > CSP s3.2 concerns all type of certificates. "Optional, relevant to the > certificate type" means that we don't ask for domain validation for e.g. > the standard certificate. We do domain validation for all SSL certifcates. > More details about process of validation during issuing certificates of > all types you can find in CP.
I don't read the CP (specifically, s2.4) as confirming "that the Applicant controls the Fully-Qualified Domain Name" (as per BR 1.1.9 s.9.2.1). > > Note that test cerificates have their own policy's distinguished > > identifier (s 2.5 CP). > > Are you asking Mozilla to blacklist certificates marked with that OID from > being trusted? If not, the fact that they have such an identifier is > irrelevant for the purposes of determining trustworthiness. > > I am not sure if Mozilla has implemented funcionality like blacklist for > certificates marked with OID. As we can see other CAs do not force their > subscriber to show their ID even during issuing non-test certificates. We > check subscribers identity face to face. That is not clear from the CPS. > > We reserve itself the right to downtime our OCSP, but it doesn't mean > that > > we do it every week during normal working hours. What is acceptable > level > > of service for you? We can adjust our technical downtime for OCSP. > > 100%. OCSP is a fundamental service for a publically-trusted CA to > provide. > Given that it can easily be run as a read-only service for a period of > time > (in your case, up to 24 hours), there is no reason why maintenance cannot > be > done entirely without interruption. > > We maintain OCSP on line 24x7. But 100% availability of is utopia. Even e- > banking systems have their downtimes. My bank doesn't go down for four hours every week, nor does it claim to be able to. If it did, I'd find another bank, but as a relying party, I can't find another CA to present a certificate for a site I wish to verify the authenticity of. > We want to be fair to the user, > that's why we inform them about possibility of downtime. We can remove > this 4 hour from CSP. I think that would be best. - Matt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
