> Le mardi 30 octobre 2012 16:55:01 UTC+1, ig...@ssi.gouv.fr a écrit :
>> You specify in your remarks that "At least 20 bits of entropy is mandatory". You are right. However,
>> it appears that the obligation of a 20 bits entropy in the serial number only concern SHA-1. Our PKI gave up this function in favour of SHA 256.

> That's the rationale, adding entropy to help defeat a prefix-chosen collision for non collision resistant hash functions. I agree that using SHA256 without entropy isn't a problem in a near future. However, the Mozilla Policy doesn't say that; the entropy is mandatory for all new certificates, the used hash function isn't taken into consideration.

> I haven't found where in the CP/CPS is stated that SHA1 isn't an acceptable hash algorithm for certificates. Moreover, in RGS-A-14 document (http://references.modernisation.gouv.fr/sites/default/files/RGS_Profi..., clause V), it is said that SHA1 is acceptable for legacy applications support.

>> The OID arc of the French Ministry of agriculture is composed of the following items :

>> - a dedicated branch to regular uses whose eighth elements can go from 10 to 19 (number 15 identifies a certificate family for authentication servers) ;
>> - a branch for advanced uses whose eighth element of the OID arc can go from 20 to 29.

> The chaining may be consistent with certifications, but you may read X.509, clause 8.2.2.6. Here's an excerpt:
> -----
> The presence of this extension in an end- entity certificate indicates the certificate policies for which this certificate is valid. The presence of this extension in a certificate issued by one CA to another CA indicates the certificate policies for which certification paths containing this certificate may be valid.
> -----

> What it means it that the certificatePolicies of a CA certificate doesn't have to contain the CP OID of this CA, but the acceptable CP OIDs of end-user certificates.

> If you follow the normalized path validation algorithm (clause 10) with this chain, the result will be a valid certificate with an empty list of valid policies. The algorithm is worded differently in RFC5280 but the result is identical.

>> Extract from the web site : “As per the CA / Browser Forum's Guidelines for EV Certs, CAs must Provide year OCSP capability for end-entity certificates That Are Issued Effective December 31, 2010. Mozilla is Considering technical ways to enforce this requirement OCSP Such That if Firefox cannot Obtain a valid response from the OCSP responder, then the certificate will not be Given EV treatment. Considering We are requiring the end-entity certificate To Provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122 # c23 Additionally, we urge all CAs OCSP To Provide for all certs, When They are not even EV.”

> You're right in that Mozilla doesn't require OCSP to be activated for *all* subscriber certificates.
> However, the audit attestation (https://bug666771.bugzilla.mozilla.org/attachment.cgi?id=661038) mentions compliance to CABForum Baseline Requirements v1.0 in a surveillance audit, and this BR states that OCSP is mandatory for subscriber certificates.

> I'll let others show their opinion on wether ANSSI-audit team auditing ANSSI-implementation team is acceptable as a qualified third-party audit. A check of other governmental CAs applications might help.