I started reading your CP/CPS and I noticed that you do not use the
standard CA/B Forum terminology. Is this on purpose? Is it just a
translation issue?

Furthermore, I believe that the English Root CA CP/CPS should be added
to the bug, I can only find the translation of the SSL SubCA CP/CPS.

And just a final note, I can't seem to be able to access the mail sent
by Gerv the 15th of August (the one I'm replying to) at the google
groups thread
Maybe it got lost somehow and the CA contacts are using google groups to
get an update on their discussion.


On 15/08/2017 03:41 μμ, Gervase Markham via dev-security-policy wrote:
> On 03/08/17 08:01, Olfa Kaddachi wrote:
>> ==> Some of these controls are already in place (such as the field CN and 
>> Subject Alternative Name that does not contain a private IP address). 
> That doesn't quite answer my question.
> Let me ask another way: for how long has the Government of Tunisia CA
> been aware of the Baseline Requirements? From what date do you assert
> that you have been compliant with these requirements?
>> 4-   Validation of the technical data included in the CSR: The RA operator 
>> checks :
>> Digital Signature Algorithm: SHA256
>> Key Algorithm: RSA
>> Key Size: 2048
> Why can such things not be checked programmatically? It seems you are
> opening yourselves up to the possibility of human error.
>> Moreover, the NDCA is now implementing a new Managed PKI platform which will 
>> be in production by the end of September 2017.  For the moment, the only 
>> improvement done, is the printing of all the subject alternative names in 
>> the certificate for the RA operators, in addition to the other fields (CN, 
>> O, OU, mail) in such a way that they can visually check all the fields 
>> before the delivery of the certificate.
> A visual check may not catch every problem. For example, would it catch
> a trailing space?
>> >From what date would you say that your CA has been compliant with the CAB 
>> >Forum Baseline Requirements? 
>> ==> The TunRootCA2 and TunServerCA2 passed two successive external audit 
>> performed by LSTI. The last audit took place from 27th to 30th September 
>> 2016 in applying the relevant ETSI Technical Specifications ETSI TS 
>> 102042v2.4.1. 
> And that audit includes a BR audit?
> Did the audit report have any qualifications?
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com
dev-security-policy mailing list

Reply via email to