On Wed, Apr 12, 2017 at 8:46 AM, Kurt Roeckx via dev-security-policy <
[email protected]> wrote:
> On 2017-04-12 14:19, Jakob Bohm wrote:
>
>> On 12/04/2017 12:44, Kurt Roeckx wrote:
>>
>>> On 2017-04-12 11:47, Gervase Markham wrote:
>>>
>>>> There are some items that it would be very helpful for auditors to state
>>>> in their public-facing audit documentation so that we can be clear about
>>>> what was covered and what was not. The policy already has some
>>>> requirements here, in section 3.1.3, mostly relating to dates.
>>>>
>>>> The proposal is to add the following bullets to section 3.1.3 ("Public
>>>> Audit Information"), perhaps reordering the list as appropriate:
>>>>
>>>> * name of the company being audited
>>>> * name and address of the organization performing the audit
>>>> * DN and SHA1 or SHA256 fingerprint of each root and intermediate
>>>> certificate that was in scope
>>>>
>>>
>>> The SHA256 of what? The certificate? There can be multiple certificates
>>> for the same CA. It should probably be made more clear, like a hash of
>>> the subject DN.
>>>
>>>
>>>
>> The operation "certificate fingerprint" is well defined and generally
>> covers most/all of the DER-encoded certificate, not just the DN. For
>> example, this value is displayed when looking at CA certificates in the
>> Firefox options dialog.
>>
>> For public CAs that don't rely on certificate distribution through
>> browser inclusion, it is also common to provide an authoritative
>> out-of-band copy of the fingerprint as something relying parties should
>> check when installing the CA root cert.
>>
>
> There might be multiple certificates for a CA, which are all valid, and
> all have a different hash. Any of those could be used, and with it we could
> clearly find which one they're talking about.
>
> But all software really should also support a "subject hash". I think this
> is for instance needed for OCSP, and might also be used to find the
> certificate in the root store. That has only 1 value for the CA, not one
> for each of the certificates for that CA.
>
> Either of those should work, and we should probably be clear about which
> one they should provide.
A subject hash would not provide distinct value over the already disclosed
DN.
A certificate hash does provide distinct value.
The certificate hash is what is desired. Yes, there could be multiple
certificates. But within the context of the scope of an audit and a
'logical' CA, the auditor can and should be clear about what physical
certificates corresponded to the logical operations of that CA.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
