Re: Symantec Response B
On 2017-04-11 17:54, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The reply indicated that it was a non-browser application. So I understand that a browser should never see that certificate. There's no way to objectively quantify or assess that, however. My question still remains - what are the criteria for determining this, and what process is in place for disagreement about this risk? The question is, can that certificate be used for authenticating something it shouldn't? And I guess that's not the case. No. That is not the question. The problem with 1024 keys is that someone with enough resources can find the private key. I assume there are no other (new) certificates with the same key. So I think there are 3 potential problems: 1) The subscriber itself can be attacked 2) The rest can't enforce the 2048 limit, so we can't be sure we're not attacked. 3) The certificate could be used to authenticate something else He said "we believed that issuance of this cert didn't impose risk on anyone but this specific customer", which would be 1). I don't think 2) applies. It's only their software, that obviously can't be updated yet, and so won't enforce such limit. That doesn't prevent the rest of us to set such limit. Which would only leave 3) Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
Hi Doug, Kathleen is unavailable this week, so I'll try and answer. (This might have been better as a new top-level post, though...) On 11/04/17 21:14, Doug Beattie wrote: > This is my understanding: > > - Under policy 2.3 a CA that is technically > constrained with EKU set to only secure email but without name > constraints was considered out of scope of the Mozilla Policy. Which parts of policy 2.3 lead you to that conclusion? https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md 2.3 does not have an explicit scope statement, something we fixed in 2.4. Policy 2.3, Application section, bullet 9, defines rules for technically constrained certificates, including a section giving rules for certs issued by technically constrained email sub-CAs. How do you then see these as out of scope? > - Policy 2.4.1 adds a requirement that for the CA to be out of scope of > the Mozilla policy the CA needs to have name constraints if the CA is > capable of issuing secure email certificates. Which parts of policy 2.4.1 lead you to that conclusion? https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Section 1.1.2 of 2.4.1 says that sub-CAs are included in the overall scope statement. There are two ways to be exempted - not be capable of issuing email certificates, or be name-constrained. So I assume you are referring to 1.1.2, bullet 2. But this says that to be exempted, you need to be not issuing any form of rfc822Name - in other words, it's a way of turning off email entirely using a different technical mechanism. This bullet is not met if you have name constraints which restrict you to particular email domains. So I would say that an email-only sub-CA which is name-constrained to certain domains is currently still in scope. And, indeed, section 5.3.1 is the new analogue of the old Application section, bullet 9 mentioned above, and contains the same language governing certs issued by technically constrained email-only sub-CAs. Of course, this is all related to: https://github.com/mozilla/pkipolicy/issues/36 :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
On 11/04/17 22:08, Eric Mill wrote: > I'll leave it to others to opine on the severity of the mistake and the > quality of the response, but I do want to at least properly communicate the > impact. Thank you. I have updated my write-up for Issue L. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Issues doc updated
On 11/04/17 23:07, Jakob Bohm wrote: > Please consider the fact that this is Easter week, and most of the > industry, including many people (on both the Browser and Symantec sides > of the process) are likely to be unavailable for precisely this week of > the entire year. > > In general, sending deadline mails (by paper, e-mail, process server or > otherwise) to anyone during a public holiday demanding actions during > that holiday is considered morally deficient at a minimum. That seems hyperbolic. However, your point is well taken. I have emailed Symantec to put back the deadline to 23:59 UTC on Thu 20th April. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Require qualified auditors unless agreed in advance
Way back when, Mozilla wrote some requirements for auditors which were more liberal than "be officially licensed by the relevant audit scheme". This was partly because organizations like CACert, who were at the time pondering applying for inclusion, might need to use unofficially-qualified auditors to keep cost down. This is no longer a live issue, and this exception/expansion causes confusion and means that we cannot unambiguously require that auditors be qualified. Therefore, I propose we switch our auditor requirements to requiring qualified auditors, and saying that exceptions can be applied for in writing to Mozilla in advance of the audit starting, in which case Mozilla will make its own determination as to the suitability of the suggested party or parties. Proposed changes: * Remove sections 3.2.1 and 3.2.2. * Change section 3.2 to say: In normal circumstances, Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2. If a CA wishes to use auditors who do not fit that definition, they MUST receive written permission from Mozilla to do so in advance of the start of the audit engagement. Mozilla will make its own determination as to the suitability of the suggested party or parties, at its sole discretion. * Change section 2.3, first bullet, to read: - Mozilla reserves the right to accept audits by auditors who do not meet the qualifications given in section 8.2 of the Baseline Requirements. This is: https://github.com/mozilla/pkipolicy/issues/63 --- 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection
Section 5.3.1 of policy 2.4.1 defines what it means to be technically constrained for email sub-CAs (those with id-kp-emailProtection). It says: "If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or mailboxes that the issuing CA has confirmed (via technical and/or business controls) that the subordinate CA is authorized to use." This is bogus. What it says here is something that you have to do for any email cert - it's not a technical constraint but a policy constraint, and it's basically the same as 2.2.2: "for a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf;" Section 5.3.1 should define technical constraints on the intermediate appropriate for restricting email addresses to a whitelist of domains, just as the section for id-kp-serverAuth restricts to a whitelist of domains. We don't have any "Email BRs" to refer to, but I think we want something like this: "If the certificate includes the id-kp-emailProtection extended key usage, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees." This is: https://github.com/mozilla/pkipolicy/issues/69 --- 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Require qualified auditors unless agreed in advance
On 12/04/2017 11:47, Gervase Markham wrote: Way back when, Mozilla wrote some requirements for auditors which were more liberal than "be officially licensed by the relevant audit scheme". This was partly because organizations like CACert, who were at the time pondering applying for inclusion, might need to use unofficially-qualified auditors to keep cost down. This is no longer a live issue, and this exception/expansion causes confusion and means that we cannot unambiguously require that auditors be qualified. Therefore, I propose we switch our auditor requirements to requiring qualified auditors, and saying that exceptions can be applied for in writing to Mozilla in advance of the audit starting, in which case Mozilla will make its own determination as to the suitability of the suggested party or parties. Proposed changes: * Remove sections 3.2.1 and 3.2.2. * Change section 3.2 to say: In normal circumstances, Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2. If a CA wishes to use auditors who do not fit that definition, they MUST receive written permission from Mozilla to do so in advance of the start of the audit engagement. Mozilla will make its own determination as to the suitability of the suggested party or parties, at its sole discretion. * Change section 2.3, first bullet, to read: - Mozilla reserves the right to accept audits by auditors who do not meet the qualifications given in section 8.2 of the Baseline Requirements. Does this (accidentally?) remove the ability of Mozilla to explicitly distrust a specific formally qualified auditor, such as E&Y HK? This is: https://github.com/mozilla/pkipolicy/issues/63 --- 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection
On 2017-04-12 11:47, Gervase Markham wrote: "If the certificate includes the id-kp-emailProtection extended key usage, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees." I think this change itself makes sense. Reading that section, I think it could use some improvements. It's for instance not really clear that this is needed "to be considered technically constrained", but I guess that's the intention. But I'm also wondering what you expect if it contains other EKUs like client auth, code sign, unknown. Do we always consider them constraint? So I'm suggesting something like: When the following EKUs are included, to be considered technically constrained, the following additional constraints should be present. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
To add to Eric's response, the U.S. Federal PKI was built and is dependent on Policy OID validation. There are 25 OIDs registered with NIST that define different assurance levels and is heavily focused on people certificates although it is a broad use PKI for the U.S. Federal Government (USG). Devices were never a big use case until HTTPS went mainstream and agencies starting leveraging their existing PKI to issue Server Auth certificates. There was a growing divide between Federal PKI policy and CAB Forum / Browsers (specifiallly with the interpretation of RFC 5280 and Intermediate CA EKU use) that the Federal Government is now trying to correct with the new NPE CP development (https://github.com/uspki/policies). The USG even set up a testing program (FIPS 201 Evaluation Program) to test PKI enabled applications and ensure they met Federal PKI requirements for policy OID validation which still exists today. It is mainly focused on non-mainstream products like physical access systems, SCVP, logical access appliances, and a couple other categories. NIST developed a PKI test suite (http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html) to test 5280, but it is kind of dated. The FIPS 201 program is updating and integrating the NIST test suite items. I'm not sure if it ever tested email, browsers, or other mainstream type programs and now cloud-based applications. That seems like a gap in ensuring policy validation worked in products and keeping the Federal PKI informed of new events in the web PKI. Adobe is the only mainstream application I know of or heard of that does policy validation for PKI vendor supplied policies. In relation to Symantec, the Federal Bridge was established as an interoperability hub using OID validation of strong to low assurance people credentials which were intermingled with device credentials (the focus primarily being on people). If you ask anyone in the Federal PKI they would say I only accept XX.XX OID and don't worry about other certificates. This is a potential issue for products that only do path validation though. That doesn't address any of the questions directed at Symantec and why the cross-cert wasn't disclosed. If browsers did policy validation would it have been a problem? I can't answer that. Here is an overview document of how the U.S. Federal PKI was designed and built (https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t000TNRIAA4&field=File__Body__s) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
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.
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response B
On Wed, Apr 12, 2017 at 4:24 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't think 2) applies. It's only their software, that obviously can't > be updated yet, and so won't enforce such limit. That doesn't prevent the > rest of us to set such limit. > Hi Kurt, I appreciate that you're engaged and offering your thoughts. I would appreciate, however, if you allowed Steve to respond on behalf of Symantec. I do not agree with your conclusions or interpretation of matters, but more importantly, the questions are for Symantec. #2 absolutely applies as a principle. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
On Wed, Apr 12, 2017 at 8:46 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
On 2017-04-12 13:42, braddockmews...@gmail.com wrote: If browsers did policy validation would it have been a problem? I can't answer that. So I guess that would be something like require one of the CAB policy IDs for which validation that happened? (2.23.140.1.2.1 for DV, 2.23.140.1.2.2 for OV, 2.23.140.1.2.3 for IV, 2.23.140.1.1 for EV). And that if none of those are present it should reject the certificate? I would clearly be in favor of those policy IDs to be always present. But there were no such policy IDs in the past, and they're still not required. The FPKI now seems to use Certificate Policies, not Policy Constraints. If they used Policy Constraints, and the browsers enforced the above policies, it would be obvious that the FPKI couldn't issue certificates that could be used to authenticate servers. I think we need both to prevent it. You indicate that they started using FPKI for server authentication. I doubt that they have been audited to follow the BR requirements, so I think it would be good that we reject them. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
On 2017-04-12 16:15, Peter Bowen wrote: On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy 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. 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include
On Wed, Apr 12, 2017 at 10:15 AM, Peter Bowen wrote: > On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy > 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 'unconstra
Re: Policy 2.5 Proposal: Require qualified auditors unless agreed in advance
On 12/04/17 11:37, Jakob Bohm wrote: > Does this (accidentally?) remove the ability of Mozilla to explicitly > distrust a specific formally qualified auditor, such as E&Y HK? Good point. Not sure, but we should make that clear. Add to the end of that exception sentence ", or refuse audits from auditors who do." Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection
On 12/04/17 11:41, Kurt Roeckx wrote: > But I'm also wondering what you expect if it contains other EKUs like > client auth, code sign, unknown. Do we always consider them constraint? Formally, we don't care if they also have those EKUs, or whether the use of those EKUs is constrained, because our root program is not concerned with those uses of certificates. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
On Wed, Apr 12, 2017 at 4:53 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 11/04/17 22:08, Eric Mill wrote: > > I'll leave it to others to opine on the severity of the mistake and the > > quality of the response, but I do want to at least properly communicate > the > > impact. > > Thank you. I have updated my write-up for Issue L. > Great. I see one inaccuracy in the text there right now: When this was drawn to their attention, Symantec did not revoke the cross-sign certificate under discussion, instead allowing it to expire (less than a month later). The cross-signature was brought to Symantec's attention in mid-February 2016. The certificate expired at the end of July 2016. The current text says "less than a month later". I believe that "less than a month later" is meant to reference the time between when Symantec obtained concurrence from the Federal PKI about undoing the cross-signature, and when the certificate expired. Identrust revoked their similar cross-signature in mid-late February, a week or so after being notified of the issue by Richard Barnes (then of Mozilla). -- Eric > > Gerv > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Eric Mill Senior Advisor, Technology Transformation Service, GSA eric.m...@gsa.gov, +1-617-314-0966 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Grace Period for Sub-CA Disclosure
On 04/04/17 12:17, Gervase Markham via dev-security-policy wrote: On 27/03/17 22:12, Andrew Ayer wrote: [ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 ] This has now been added to the policy 2.5 draft with a one-week deadline. Gerv Gerv, Mozilla also requires CAs to disclose intermediate cert revocations to CCADB. Should there be a corresponding time limit in the policy regarding how soon after revocation this disclosure must occur? https://crt.sh/mozilla-disclosures#disclosedbutincrl currently shows 2 GlobalSign EV intermediates that were revoked by Google Trust Services 5 days ago, but which are still unrevoked according to CCADB. By when must GTS notify CCADB of these 2 revocations? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 serverAuth cert issued by Trustis in November 2016
Is there an expectation of a resolution of some sort to this matter? Also, their most recent audit is apparently overdue (perhaps related to the SHA-1 mis-issuance?) https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/-689uFoXBwAJ On Thursday, March 16, 2017 at 7:00:51 AM UTC-4, Gervase Markham wrote: > Hi Blake, > > On 02/03/17 16:26, blake.mor...@trustis.com wrote: > > We have engaged with our external auditors in relation to this and the > > previous certificate that was reported. Once that activity has concluded we > > will be providing further information. > > Do you have an ETA for this incident report? It's been quite some time > now. I am still interested to understand how a "full investigation" of > the first certificate failed to turn up the second. > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection
On 12/04/17 10:47, Gervase Markham via dev-security-policy wrote: Section 5.3.1 of policy 2.4.1 defines what it means to be technically constrained for email sub-CAs (those with id-kp-emailProtection). It says: "If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or mailboxes that the issuing CA has confirmed (via technical and/or business controls) that the subordinate CA is authorized to use." This is bogus. Gerv, FYI what you're proposing here (https://github.com/mozilla/pkipolicy/issues/69) was slated to appear in v2.1 of the policy, but it was vetoed by Symantec. Here's why... https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/l1BAEHjKe8Q/mey4WREKpooJ -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Symantec Response B
I am curious about the software requiring the 1024 bit cert off the root. The dates of mis-issuance are 2013-2014, which is still early in adoption of the BRs. At that time, the scope of the BRs was confusing and lead to lots of discussions. Although the term "intended to be used for authenticating servers" is still the scope of the BRs, everyone seems to agree that this means all certs with serverAuth are included. This was not the case in 2013. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, April 12, 2017 6:40 AM To: Kurt Roeckx Cc: mozilla-dev-security-policy Subject: Re: Symantec Response B On Wed, Apr 12, 2017 at 4:24 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't think 2) applies. It's only their software, that obviously > can't be updated yet, and so won't enforce such limit. That doesn't > prevent the rest of us to set such limit. > Hi Kurt, I appreciate that you're engaged and offering your thoughts. I would appreciate, however, if you allowed Steve to respond on behalf of Symantec. I do not agree with your conclusions or interpretation of matters, but more importantly, the questions are for Symantec. #2 absolutely applies as a principle. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
