On Monday, February 5, 2018 at 6:03:55 PM UTC+2, Julien Cristau wrote: > Re Section 3.4, you seem to assume the domain holder is a ComSign > subscriber. In case of misissuance, that may not be true. >>> I understand, for that we added on the CPS on section 3.4 the following: "For the handling of revocation requests by other than the Subscriber or his/her representative, refer to Section 4.9 below."
> Cheers, > Julien > > On Mon, Feb 5, 2018 at 4:23 PM, YairE via dev-security-policy < > [email protected]> wrote: > > > Hi, thank you for pointing the above > > Here is our response: > > > > Section 1.3.2.5 > > We have corrected our CPS now that only limited actions could be performed > > by DTP's > > And they cannot perform domain validation. > > > > Section 3.2.2.4 > > We are aware of the problems with the methods that have been raised, we > > thought that as long as they are permitted in the BR we would keep them > > included on our CPS, of course that we prefer not to use them and will use > > the more secured methods like 3.2.4.4.2, 3.2.4.4.3 etc. > > >After reviewing the January Communication we have removed the problematic > > methods from our CPS entirely. > > > > Section 3.2.2.8 > > As Ryan mentioned Comsign’s CAA identifier is documented on section > > 4.2.1.1(v) > > We also added it in section 3.2.2.8 now > > > > Section 3.4 > > I do not understand why does Ryan claim that a domain holder cannot > > request a revocation in case of misissuance, it clearly states that any > > subscriber could revoke any certificate for any reason he seems fit as long > > as they are identified. > > > > You can see all the updates on our CPS in our site repository: > > https://www.comsign.co.il/repository/ > > on our UK site: > > https://www.comsign.co.uk/?page_id=1282 > > and in this link as well: > > https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf > > > > Particularly Concerning > > The software we are currently using is RSA CA 6.7 on Solaris. > > As we mentioned we are now under audit on the new Microsoft CA and in the > > process of moving to that software instead of our old software. > > _______________________________________________ > > 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
