Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

[Gervase Markham]

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
* audit criteria (with version number) that were used to audit each of
the certificates
* For ETSI, a statement that the audit was a full audit, and which parts
of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP,
EVCP+, Part1 (General Requirements), and/or Part 2 (Requirements for
trust service providers).

This is: https://github.com/mozilla/pkipolicy/issues/58 and
https://github.com/mozilla/pkipolicy/issues/28 .

-------

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates

[Jakob Bohm]

On 12/04/2017 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

Maybe just SHA256, since SHA1 is mostly dead.

> * audit criteria (with version number) that were used to audit each of
> the certificates
> * For ETSI, a statement that the audit was a full audit, and which parts
> of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP,
> EVCP+, Part1 (General Requirements), and/or Part 2 (Requirements for
> trust service providers).
>
> This is: https://github.com/mozilla/pkipolicy/issues/58 and
> https://github.com/mozilla/pkipolicy/issues/28 .
>
> -------
>
> This is a proposed update to Mozilla's root store policy for version
> 2.5. Please keep discussion in this group rather than on Github. Silence
> is consent.
>
> Policy 2.4.1 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
> Update process:
> https://wiki.mozilla.org/CA:CertPolicyUpdates
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Kurt Roeckx]

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.


Kurt

[Jakob Bohm]

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.

[Kurt Roeckx]

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.


Kurt

[Ryan Sleevi]

On Wed, Apr 12, 2017 at 8:46 AM, Kurt Roeckx via dev-security-policy <
dev-secur...@lists.mozilla.org> 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.

[Peter Bowen]

On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> 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.

What portions of the certificate(s) naming that CA as the subject will
impact the audit?

As I see it, the only certificates that are relevant to the audit are
those that have the CA as the issuer. It really doesn't matter who
cross-signs the CA.

Thanks,
Peter

[Kurt Roeckx]

Note that it's about each root and intermediate certificate. For the
intermediate's the issuer doesn't really matter, it's the subject you
care about.

I just noticed that the text also says certificate while I expected it
to say CA.


Kurt

[Ryan Sleevi]

On Wed, Apr 12, 2017 at 10:15 AM, Peter Bowen <pzb...@gmail.com> wrote:

> On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
> >
> > 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.
>
> What portions of the certificate(s) naming that CA as the subject will
> impact the audit?
>
> As I see it, the only certificates that are relevant to the audit are
> those that have the CA as the issuer. It really doesn't matter who
> cross-signs the CA.
>

So we talked about this (briefly) during the CA/Browser Forum F2F 40 in
Raleigh, but:

As you know, RFC 5280 defines a trust anchor as a DN/Key tuple as the basis
for trust. That is, if a thing signed by a CA bears a particular DN in the
field, we say that it was 'issued' by that CA
- CAs can issue different things using a single key, governed by the
relevant specification
- For example, if a TBSCertificate (
https://tools.ietf.org/html/rfc5280#section-4.1 ) contains the given DN in
the Issuer field, and is signed by the associated key (creating a
Certificate), then we say the CA issued the Certificate
- For example, if a TBSCertList (
https://tools.ietf.org/html/rfc5280#section-5.1 ) contains the given DN in
the Issuer field, and is signed by the associated key (creating a
CertList), then we say the CA issued the CRL
- For example, if a CA's key is used to sign a ResponseData (
https://tools.ietf.org/html/rfc6960#section-4.2.1 ) in the production of a
BasicOCSPResponse, then we say the CA issued the OCSP response (notably,
there's no encoding of the Issuer DN within the ResponseData beyond that of
the CertID, which comes from the request and contains the hash of the
Issuer DN and Issuer Key, but not their actual values; the binding to the
CA comes from the unsigned portion of the BasicOCSPResponse which
establishes the certificate chain of the issuer, or is implied to be the
issuer of the current CertID if absent)
- For example, if a CA's key is used to sign a TBSCertificate (
https://tools.ietf.org/html/rfc5280#section-4.1 ) containing the given DN
in the Issuer field, a critical poison extension (
https://tools.ietf.org/html/rfc6962#section-3.1 ) and signed by the
associated key (creating a Certificate), then we say the CA issued the
Precertificate (the confusion and complexity here about whether a
Precertificate-is-a-Cert is well known)

I mention all of these examples to illustrate that the act is with the key,
and whether or not it was 'issued' determines on where, how, and if the
given ASN.1 structure encodes the DN. There's a whole host of complexity
there - for example, if I create a Sleevi-ID and submit to the IETF that
uses the same ASN.1 structure of a Certificate/TBSCertificate, but name it
differently (and perhaps use slightly different encoding, such as omitting
the DEFAULT production rule for some fields in the syntax), is that or is
that not a certificate?

Now further, imagine a given CA has multiple certificates bearing the
associated DN in the Subject, and sharing the same key. This might be the
common case of having a self-signed certificate and one which may be
cross-signed by either the same legal entity or a different legal entity.

One of these certificates contains no nameConstraints extension (and the
subject and issuer match)
Another of these certificates contains a nameConstraints extension
restricting its issuance practices to test.example (and a different issuer)

I take that private key and copy it between two distinct infrastructures.
The first infrastructure is my publicly trusted infrastructure. The second
is what I call my 'test' instance. Both are independently maintained and
operated, and responsible for their own serial number production (e.g. they
may collide)

I issue all sorts of 'evil' certs from the latter infrastructure (e.g. I
don't perform domain validation). All of these I claim are benign, because
nameConstraints means they are not processed as valid. Except for the fact
that all of these 'evil' certs could be intepreted as chaining to the first
CA (and thus be actively used for nefarious purposes).

Now, if the auditor only comes in and examines the first infrastructure -
the one that is acting properly - and issues an audit report, then they
will have only examined one part of the issuance infrastructure, and only
in the 'context' of the self-signed, well-behaving certificate. Without
binding that audit to the certificate, my evil self can take that audit
report and present it as being binding to my 'evil' infrastructure as proof
that I have acted good and well, despite not having done so.

You can also imagine the inverse (where the 'name constrained'
infrastructure is the good infrastructure, but the 'unconstrained'
infrastructure is the evil infrastructure), and you end up with
transplantation issues.

So the goal of binding not just to the name and key but also the
certificate is an attempt to reduce the ambiguity and guarantee the scoping
is related to what was examined.

Other variations of this issue still exist. For example, if I encode my DN
using printableString using one format, but UTF8String using another, can I
attempt to do transplantation of audit statements across these name types?
Hashing the name makes it more specific (since there's a specific sequence
of bytes), and providing the name in textual, unencoded form makes it more
general (since it assumes to all encodings of that sequence with that key)

I'm not suggesting this comprehensively addresses the issues. I'm not
suggesting this paranoia is warranted, other than I'm amazed by the ability
of CAs to interpret the BRs and policies in the strangest of ways. Thus I
assume that any statements will be interpreted either by a literal genie
<http://tvtropes.org/pmwiki/pmwiki.php/Main/LiteralGenie> or a jackass genie
<http://tvtropes.org/pmwiki/pmwiki.php/Main/JackassGenie>, and try to
address that as best possible.

[Gervase Markham]

On 12/04/17 10:47, Gervase Markham wrote:
> The proposal is to add the following bullets to section 3.1.3 ("Public
> Audit Information"), perhaps reordering the list as appropriate:

Adopted as proposed, with the exception (for simplicity) of removing the
option of providing a "SHA1" fingerprint.

Gerv