RE: Clarification request: ECC subCAs under RSA Root

2021-03-10 Thread Tim Hollebeek via dev-security-policy
I know where this kind of requirement is coming from ... it's a common
requirement in key management systems, but they generally operate in worlds
that are completely different from the Web PKI.  Even there, it often causes
more problems than it solves.  I've spent more of my life dealing with the
fallout from rules like this than I care to admit.

It makes more sense when you have a complex asymmetric or symmetric system
with different strength keys protecting the distribution of symmetric keys
with different strengths, and you want to make sure the keys being
distributed actually have the intended strength, instead of being somewhat
weaker due to potential attacks on weak links in the distribution system.
One of the ways of simplifying that complexity is to enforce various
uniformity requirements on the chains.  This helps prevent accidentally
using an encryption key that was distributed with a weaker key, and thinking
that it has full strength.

It's important to remember that TLS keys are real-time online authentication
keys, generally with relatively short lifetimes (relative to many typical
KMSs!), and the goal is to meet the minimum authentication strength goal at
the time the connection is being built.  Whether one or more keys is a bit
stronger than necessary doesn't hurt anything in the same way that it can
for encryption keys.  And as the two previous people have noted, mixed
chains can be extremely useful in various interoperability and
transition/upgrade scenarios.  So rules like these can actually reduce
cryptoagility by unnecessarily eliminating perfectly viable options, and
reducing cryptoagility is the exact opposite of what we should be trying to
accomplish.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, March 10, 2021 11:00 AM
> To: pfuen...@gmail.com 
> Cc: Mozilla 
> Subject: Re: Clarification request: ECC subCAs under RSA Root
> 
> I agree with Corey that this is problematic, and wouldn't even call it a
best
> practice/good practice.
> 
> I appreciate the goal in the abstract - which is to say, don't do more
work than
> necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting cycles
*if*
> there's no other reason for it), but as Corey points out, there are times
where
> it's both necessary and good to have such chains.
> 
> On Wed, Mar 10, 2021 at 9:46 AM pfuen...--- via dev-security-policy < dev-
> security-pol...@lists.mozilla.org> wrote:
> 
> > > My understanding is that neither the BRs or any Root Program require
> > that that subordinate CA key be weaker or equal in strength to the
> > issuing CA's key.
> > >
> > > Additionally, such a requirement would prohibit cross-signs where a
> > "legacy" root with a smaller key size would certify a new root CA with
> > a stronger key. For that reason, this illustrative control seems
problematic.
> > >
> >
> > Thanks, Corey.
> > I also see it problematic, but I've been seeing other root programs
(i.e.
> > Spanish Government) enforcing this rule, so I'd like to understand if
> > it's a "best practice" or a rule, and, in particular, if it's rule to
> > be respected for TLS-oriented hierarchies.
> > P
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> 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


RE: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

2020-11-06 Thread Tim Hollebeek via dev-security-policy
In the definition of EV TLS Capable, I'd move the last bullet up to the top.

This is because the definition is inherently recursive, and it's easy to
miss that 
if the recursion rule isn't first.

For example, I had a question about whether "revoked" meant just the
certificate
itself, or whether a revoked parent (etc) also qualifies.  But the ambiguity
goes 
away once you realize that the parent/cross/etc also needs to be EV TLS
Capable, 
hence not revoked.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Kathleen Wilson via dev-security-policy
> Sent: Thursday, November 5, 2020 7:28 PM
> To: Mozilla 
> Subject: Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for
Policy
> Constraints
> 
> On 10/16/20 11:26 PM, Ryan Sleevi wrote:
> > Because of this, it seems that there is a simpler, clearer,
> > unambiguous path for CAs that seems useful to move to:
> > - If a CA is trusted for purpose X, that certificate, and all
> > subordinate CAs, should be audited against the criteria relevant for X
> >
> 
> I am in favor of this approach for a future version of Mozilla's Root
Store
> Policy, but I prefer not to try to tackle it in this v2.7.1 update.  So I
filed a
> github issue to remind us to consider this in the next version:
> 
> https://github.com/mozilla/pkipolicy/issues/220
> 
> 
> I have added a section called "EV TLS Capable" to the wiki pages, and I
will
> appreciate feedback on it:
> 
> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
> 
> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
> occurrence of "capable of issuing EV certificates" link to
> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable
> 
> Thanks,
> Kathleen
> 
> ___
> 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


RE: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

2020-11-05 Thread Tim Hollebeek via dev-security-policy
Ben,

We're concerned that these changes could unintentionally prevent many new 
auditors from being able to conduct audits, despite being Qualified Auditors.  
The problem is that CAs will understandably be very hesitant to use a new 
auditor, as they cannot risk having an audit conducted, and then not accepted 
by Mozilla.  An unfortunate effect of that is that CAs will likely only 
consider auditors who have a previous history of being accepted as qualified.

One potential solution is to allow CAs to ask Mozilla to "pre-vet" a potential 
auditor they would like to use.  Mozilla policy already has a process in the 
next paragraph to provide opinions on auditors who "do not fit the definition 
of Qualified Auditor" that could potentially be re-used.  Unfortunately, as the 
paragraph is currently worded, it can only be used for auditors who are *NOT* 
Qualified, which is really weird.

It would be helpful to clarify that CAs MAY use the same procedure to work with 
Mozilla to determine whether a particular auditor is Qualified or not, prior to 
the beginning an engagement.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Tuesday, November 3, 2020 6:53 PM
> To: Mozilla 
> Subject: Policy 2.7.1: MRSP Issue #192: Require information about auditor
> qualifications in the audit report
> 
> Historically, Mozilla Policy required that CAs "provide attestation of their
> conformance to the stated verification requirements and other operational
> criteria by a competent independent party or parties with access to details of
> the CA's internal operations."
> https://wiki.mozilla.org/CA:CertificatePolicyV1.0  "Competency" was "for
> whom there is sufficient public information available to determine that the
> party is competent to judge the CA's conformance to the stated criteria. In 
> the
> latter case the 'public information' referred to should include information
> regarding the party's:
> 
>- knowledge of CA-related technical issues such as public key
>cryptography and related standards;
>- experience in performing security-related audits, evaluations, or risk
>analyses; *and*
>- honesty and objectivity."
> 
> Today, section 3.2 of the MRSP
>  group/certs/policy/#32-auditors>
> states, "In normal circumstances, Mozilla requires that audits MUST be
> performed by a Qualified Auditor, as defined in the Baseline Requirements
> section 8.2," but under section 2.3  US/about/governance/policies/security-group/certs/policy/#23-baseline-
> requirements-conformance>,
> "Mozilla reserves the right to accept audits by auditors who do not meet the
> qualifications given in section 8.2 of the Baseline Requirements, or refuse
> audits from auditors who do."
> 
> Section 8.2 of the Baseline Requirements states an auditor must have:
> 1. Independence from the subject of the audit; 2. The ability to conduct an
> audit that addresses the criteria specified in an Eligible Audit Scheme (see
> Section 8.1); 3. Employs individuals who have proficiency in examining Public
> Key Infrastructure technology, information security tools and techniques,
> information technology and security auditing, and the third-party attestation
> function; 4. (For audits conducted in accordance with any one of the ETSI
> standards) accredited in accordance with ISO 17065 applying the requirements
> specified in ETSI EN 319 403; 5. (For audits conducted in accordance with the
> WebTrust standard) licensed by WebTrust; 6. Bound by law, government
> regulation, or professional code of ethics; and 7. Except in the case of an
> Internal Government Auditing Agency, maintains Professional Liability/Errors
> & Omissions insurance with policy limits of at least one million US dollars in
> coverage
> 
> It is proposed in Issue #192
>  that information about
> individual auditor's qualifications be provided--identity, competence,
> experience and independence. (For those interested as to this independence
> requirement, Mozilla Policy v.1.0 required either disclosure of the auditor's
> compensation or the establishment that the auditor "is bound by law,
> government regulation, and/or a professional code of ethics to render an
> honest and objective judgement regarding the CA.")
> 
> While subsection 3 of BR 8.2 requires "individuals who have proficiency in
> examining Public Key Infrastructure technology, information security tools and
> techniques, information technology and security auditing, and the third-party
> attestation function," that fact needs evidence in order to be established. 
> The
> proposed resolution of this Issue #192 intends to accomplish that.
> 
> This proposal to require disclosure of individual auditor qualifications is 
> very
> similar to the approach adopted by the U.S. Federal PKI
> 

RE: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

2020-11-05 Thread Tim Hollebeek via dev-security-policy
So, I'd like to drill down a bit more into one of the cases you discussed.
Let's assume the following:

1. The CAO [*] may or may not have requested removal of the CAC, but removal
has not been completed.  The CAC is still trusted by at least one public
root program.

2. The CAO has destroyed the CAK for that CAC.

The question we've been discussing internally is whether destruction alone
should be sufficient to get you out of audits, and we're very skeptical
that's desirable.

The problem is that destruction of the CAK does not prevent issuance by
subCAs, so issuance is still possible.  There is also the potential
possibility of undisclosed subCAs or cross relationships to consider,
especially since some of these cases are likely to be shutdown scenarios for
legacy, poorly managed hierarchies.  Removal may be occurring *precisely*
because there are doubts about the history, provenance, or scope of previous
operations and audits.

We're basically questioning whether there are any scenarios where allowing
someone to escape audits just because they destroyed the key is likely to
lead to good outcomes as opposed to bad ones.  If there aren't reasonable
scenarios where it is necessary to be able to remove CACs from audit scope
through key destruction while they are still trusted by Mozilla, it's
probably best to require audits as long as the CACs are in scope for
Mozilla.

Alternatively, if there really are cases where this needs to be done, it
would be wise to craft language that limits this exception to those
scenarios.

-Tim

[*] I'm going to use the terms CAx, where x = { Organization, Certificate,
Key }, to avoid the ambiguities in the term "CA".

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, November 4, 2020 2:04 PM
> To: Corey Bonnell 
> Cc: Mozilla 
> Subject: Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous
Audits
> 
> (Aside: Congrats on the new e-mail address)
> 
> The question here is what does "the grave" mean. A common response from
> CAs is "Oh, we stopped issuing TLS certificates from that X years ago,
that's
> why we don't have audits this year", even though a given root (**or**
> subordinate) is still included/transitively trusted.
> 
> The goal is to capture that the obligation of a CA exists until they are
fully
> removed, or until they destroy the key.
> 
> This also addresses another concern that we saw with the SHA-1
deprecation,
> in which CA's would give notice on a Monday "Please remove our root
> certificate", and then expect that, by Tuesday, they could ignore Mozilla
policy
> requirements and the BRs. That doesn't work, because unless/until the CA
is
> fully removed, Mozilla users, and the broader ecosystem, are at risk. So
this is
> intended to prevent that scenario, by highlighting that merely asking for
> removal isn't sufficient, the removal needs to be completed. And, if that
takes
> too long, the CA has an option to destroy the key (e.g. if they're going
out of
> business).
> 
> For the situation you describe, of transference of key material
> control/ownership, that responsibility still continues, plus the added
> intersection of the Section 8 requirements regarding such transfer. The
new
> organization is responsible for providing those continuing audits, or, if
they
> don't like that obligation, the destruction of key material. There's still
> "devious" things that can happen; e.g. old-CA notifies Mozilla on Monday,
> Mozilla approves on Tuesday, new CA requests removal on Wednesday, new
> CA begins shenanigans on Thursday, it's reasonable to ask whether or not
old-
> CA knew that new-CA was going to get up to mischief and what the
> implications are. But that's stuff that would nominally get sorted out on
> Tuesday.
> 
> Note that some of this discussion comes from 2 years ago in the CA/B Forum
in
> Shanghai, at https://cabforum.org/2018/10/18/minutes-for-ca-browser-
> forum-f2f-meeting-45-shanghai-17-18-october-2018/#28-Audit-requirements-
> over-the-lifecycle-of-a-root
> 
> On Wed, Nov 4, 2020 at 10:14 AM Corey Bonnell via dev-security-policy <
dev-
> security-pol...@lists.mozilla.org> wrote:
> 
> > I reviewed the associated GitHub commentary on the following change:
> >
> > "Full-surveillance period-of-time audits MUST be conducted and updated
> > audit information provided no less frequently than **annually** until
> > the CA certificate is no longer trusted by Mozilla's root store.
> > Successive audits information provided no less frequently than
> > **annually** from the time of CA key pair generation until the CA
> > certificate is no longer trusted by Mozilla's root store or until all
> > copies of the CA private key have been completely destroyed, as
> > evidenced by a Qualified Auditor's key destruction report, whichever
> > occurs sooner."
> >
> > and I'm having difficulty understanding why there is a new stipulation
> > to allow for key destruction reports to releas

RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-02 Thread Tim Hollebeek via dev-security-policy
So, from our perspective, the security implications are the most important here.
We understand them, and even in the absence of any compliance obligations they
would constitute an unacceptable risk to trustworthiness of our OCSP responses,
so we have already begun the process of replacing the ICAs we are responsible 
for.
There are already several key ceremonies scheduled and they will continue 
through
the holiday weekend.  We're prioritizing the ICAs that are under the control of 
third 
parties and/or outside our primary data centers, as they pose the most risk.  
We are
actively working to mitigate internal ICAs as well.  Expect to see revocations 
start
happening within the next day or two.

I understand the attraction of using a BR compliance issue to attract attention 
to
this issue, but honestly, that shouldn't be necessary.  The BRs don't really 
adequately
address the risks of the OCSPSigning EKU, and there's certainly lots of room for
improvement there.  I think, especially in the short term, it is more important 
to
focus on how to mitigate the security risks and remove the inappropriate EKU 
from
the affected ICAs.  We can fix the BRs later.

It's also important to note that, much like SHA-1, this issue doesn't respect 
the 
normal assumptions about certificate hierarchies.  Non-TLS ICAs can have a 
significant
impact on their TLS-enabled siblings.  This means that CA review needs to extend
beyond the certificates that would traditionally be in scope for the BRs.

I would also caution CAs to carefully analyze the implications before blindly 
adding the
pkix-ocsp-nocheck extension to their ICAs.  That might fix the compliance issue,
but in the grand scheme of things probably makes the problem worse, as ICAs
have fairly long lifetimes, and doing so effectively makes the inadvertent 
delegated
responder certificate unrevokable.  So while the compliance problems might be
fixed, it makes resolving the security issues much more challenging.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Thursday, July 2, 2020 12:31 AM
> To: Peter Gutmann 
> Cc: r...@sleevi.com; Mozilla  pol...@lists.mozilla.org>
> Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the
> Dangerous Delegated Responder Cert
> 
> On Wed, Jul 1, 2020 at 11:48 PM Peter Gutmann
> 
> wrote:
> 
> > Ryan Sleevi via dev-security-policy
> > 
> > writes:
> >
> > >Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> > include
> > >an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated
> > >Responder within Section 4.2.2.2 as indicated by the presence of the
> > id-kp-
> > >OCSPSigning as an EKU.
> >
> > Unless I've misread your message, the problem isn't the presence or
> > not of a nocheck extension but the invalid presence of an OCSP EKU:
> >
> > >I've flagged this as a SECURITY matter [...] the Issuing CA has
> > >delegated
> > the
> > >ability to mint arbitrary OCSP responses to this third-party
> >
> > So the problem would be the presence of the OCSP EKU when it shouldn't
> > be there, not the absence of the nocheck extension.
> 
> 
> Not quite. It’s both.
> 
> The BR violation is caused by the lack of the extension.
> 
> The security issue is caused by the presence of the EKU.
> 
> However, since some CAs only view things through the lens of BR/program
> violations, despite the sizable security risk they pose, the compliance 
> incident
> is what is tracked. The fact that it’s security relevant is provided so that 
> CAs
> understand that revocation is necessary, and that it’s also not sufficient,
> because of how dangerous the issue is.
> ___
> 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


RE: Terms and Conditions that use technical measures to make it difficult to change CAs

2020-04-16 Thread Tim Hollebeek via dev-security-policy
Generally, I'm in favor of transparency requirements, and many of Ryan's ideas
would be useful or interesting to pursue.  Transparency is often the first and 
best 
step towards improving business practices.  And the entire purpose of a CPS is 
to 
disclose the business practices that implement a particular certificate policy 
(e.g. the Baseline Requirements).  So I think it's entirely appropriate that 
Mozilla 
and other root  policies consider and implement disclosure policies that 
mandate 
that certain security-relevant business practices be disclosed.  Such 
requirements 
have even appeared in the Baseline Requirements from time to time, and should
continue to do so.

Unfortunately, some CAs have chosen to use CPSs that have very little content 
other
than "we comply with the baseline requirements".  Root programs have taken a
variety of stances on this in the past.  For example, Mozilla has required CAs 
to
actually disclose which validation methods they use, as opposed to which they
_might_ use (all of them!).  On the other hand, for example in Shanghai, some
have argued that there is nothing wrong with a CPS that does not disclose 
anything
about how CAs implement any of the policy requirements.

I personally find myself in the transparency camp, and would prefer that when
the details of how a CA complies with a particular requirement is security 
relevant,
it would be an improvement if those details were disclosed.  But that's in 
conflict
with the "Default Non-disclose" policy that many people, both on the root 
program
and CA side, have advocated for.

I would personally find it very unfortunate if the trend continues, and we have
increasingly vacuous CPSs that contain no relevant information.  But in the 
absence
of requirements to disclose relevant practices, I'm not surprised that that's a 
trend
that has been embraced by some CAs.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Robin Alden via dev-security-policy
> Sent: Tuesday, April 14, 2020 8:13 PM
> To: r...@sleevi.com
> Cc: Mozilla 
> Subject: RE: Terms and Conditions that use technical measures to make it
> difficult to change CAs
> 
> > .. There’s plenty of precedent in having Root Policy or the Baseline
> > Requirements require a CP/CPS explicitly state something; examples
> > such as the CAA domain name, the problem reporting mechanism and
> > contact address, and compliance to the latest version of the BRs.
> >
> > If we apply that idea here, it might make sense to require the CA’s
> > CP/CPS make a clear and unambiguous statement about whether or not
> > they engage in X as a practice. I’m not quite sure what X should say,
> > but the idea is that it would be transparent to Relying Parties
> > wanting to evaluate a CA, as well as to User Agents when evaluating
> > whether or not a given CA's practices provide a service relevant to
> > user's of that software product. While it's conceivable that sites are
> > already having these practices disclosed to them, having a consistent
> > and public disclosure would help bring transparency into what CAs are
> > engaging in this practice, and which have committed not to use
> > revocation in this way, which can help make it easier to compare the
> > trustworthiness of CAs up-front.
> 
> I am ambivalent to the idea of having a list of business practices, presumably
> over and above those required in law, that CAs must publish to the
> community.
> I suppose that CAs' existing contractual terms, particularly for large
> subscribers such as enterprise organizations, are negotiated between the
> two parties and so are typically known only to the CA and to the subscriber.
> For other individual subscribers a standard subscriber agreement published in
> advance more likely applies.
> I'm sure that some subscribers will be happy to have additional oversight of
> contractual terms rather than rely on their own reading and understanding of
> the contract they sign, while others would not choose it, were that choice
> available to them.
> 
> Paraphrasing Jeremy's answer, actions speak louder than words.
> Are these things that have been done, or things that contracts permit?
> Is it words or actions that you seek to restrict?
> 
> Kathleen posted this on the Mozilla PKI Policy github.
> https://github.com/mozilla/pkipolicy/issues/208
> saying
> > ".. some CAs have Terms and Conditions which say that if the customer
> > moves to (or even tries to use) another CA, all of their certificates
> > will be revoked. Enforcing all revocations (independent of reason)
> > supports this bad behavior by CAs, helping them to hold their
> > customers hostage. But if CAs always add the CRLReason for
> > revocations, we can selectively enforce revocation for certain
> > reasons, and have varying levels of enforcement (e.g. overridable
> > versus
> > not-overridable)
> 
> Enforcing or restricting some revocation reasons is an interesting idea but I
> think that selective implementatio

RE: About upcoming limits on trusted certificates

2020-03-17 Thread Tim Hollebeek via dev-security-policy

> On 3/11/20 3:51 PM, Paul Walsh wrote:
> > Can you provide some insight to why you think a shorter frequency in
> domain validation would be beneficial?
>
> To start with, it is common for a domain name to be purchased for one year.
> A certificate owner that was able to prove ownership/control of the domain
> name last year might not have renewed the domain name. So why should
> they be able to get a renewal cert without having that re-checked?

This has been a favorite point of Jeremy's for as long as I've been 
participating
in the CA/Browser Forum and on this list.  Tying certificate lifetimes more
closely to the lifetime and validity of the domains they are protecting would
actually make a lot of sense, and we'd support any efforts to do so.

-Tim


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


RE: Acceptable forms of evidence for key compromise

2020-03-17 Thread Tim Hollebeek via dev-security-policy
I agree with Corey on this.  I was disappointed that the LAMPS discussion two
years ago was not as helpful as it could have been.

For what it's worth, while we generally try to accept any reasonable proof of 
key
compromise, we have seen quite a large variety of things sent to us.  This 
includes
people actually sending us private keys in various forms, which is completely
unnecessary and something we'd like to avoid.

When we are unable to verify a proof, we provide explicit instructions on how 
to
create a proof in a standardized form that's easy to very.  I believe it
currently involves signing something with openssl, so it should be easy to 
carry
out for anyone who is involved in these sorts of discussions and has access to
the private key.

Standardized procedures (plural, I don't think a one size fits all solution 
would
necessarily be good) would be very helpful for everyone, including mitigating 
the risk that
some less sophisticated CAs accept proofs that are not valid, introducing a 
potential
denial of service attack.  The whole purpose of having minimum security 
requirements
is to make sure important things like this are handled correctly, using 
procedures
that have received appropriate scrutiny from individuals who understand the
security implications.

I also think it's potentially useful to discuss standardizing lists of known 
compromised
keys, and how to check them before issuance.  The problem of revoking them
could be avoided entirely if they were never issued in the first place.

BTW the same is currently true for proving domain control for the purposes of
revocation ... existing practice for CAs is currently all over the map, and 
we've
discussed it before without reaching a resolution.  It would be useful if 
there
were actual requirements for that, too.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Corey Bonnell via dev-security-policy
> Sent: Monday, March 2, 2020 2:48 PM
> To: Nick Lamb ; Mozilla  pol...@lists.mozilla.org>
> Cc: Matt Palmer 
> Subject: RE: Acceptable forms of evidence for key compromise
>
> There was quite a bit of discussion on the development of a standard
> revocation request format on LAMPS WG mailing list two years ago in the
> wake of the Trustico mass revocation:
> https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-
> Q_47QKNdyOOxsAT3Zk/.
> Nothing was developed in terms of a concrete proposal specifying a
> revocation request format/protocol, but the pros/cons of such were hashed
> out pretty thoroughly.
>
> I do think there's value in developing some standard mechanism to request
> revocation/demonstrate possession of the private key. The use of such a
> mechanism would reduce the burden of work for those reporting key
> compromises, as the reporter would not need to learn how to demonstrate
> possession the private key 15 different ways to 15 different CAs. And CAs
> would benefit from such a mechanism, as they wouldn't need to spend
> support cycles working with the reporter to arrive at a suitable means to
> demonstrate possession or have to learn some exoteric software tooling
> that the reporter is using to prove possession.
>
> Thanks,
> Corey
>
> -Original Message-
> From: dev-security-policy 
> On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Monday, March 2, 2020 2:35 PM
> To: dev-security-policy@lists.mozilla.org
> Cc: Matt Palmer 
> Subject: Re: Acceptable forms of evidence for key compromise
>
> On Mon, 2 Mar 2020 13:48:55 +1100
> Matt Palmer via dev-security-policy
>  wrote:
>
> > In my specific case, I've been providing a JWS[1] signed by the
> > compromised private key, and CAs are telling me that they can't (or
> > won't) work with a JWS, and thus no revocation is going to happen.
> > Is this a reasonable response?
>
> I don't hate JWS, but I can see Ryan's point of view on this. Not every
> "proof" is easy to definitively assess, and a CA doesn't want to get into 
> the
> game of doing detailed forensics on (perhaps) random unfounded claims.
>
> Maybe it makes sense for Mozilla to provide in its policy (without limiting
> what else might be accepted) an example method of demonstrating Key
> Compromise
> which it considers definitely sufficient ?
>
> I'd also be comfortable with such an example in the BRs, if people think
> that's the right place to do this.
>
>
> Nick.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://scanmail.trustwave.com/?c=4062&d=-
> d_d3pcpfBniFU3M4wE7RXWpZKF7oGE841cFGIoHqA&s=5&u=https%3a%2f%
> 2flists%2emozilla%2eorg%2flistinfo%2fdev-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


Terms and Conditions that use technical measures to make it difficult to change CAs

2020-03-16 Thread Tim Hollebeek via dev-security-policy
 

Hello,

 

I'd like to start a discussion about some practices among other commercial
CAs that have recently come to my attention, which I personally find
disturbing.  While it's perfectly appropriate to have Terms and Conditions
associated with digital certificates, in some circumstances, those Terms and
Conditions seem explicitly designed to prevent or hinder customers who wish
to switch to a different certificate authority.  Some of the most disturbing
practices include the revocation of existing certificates if a customer does
not renew an agreement, which can really hinder a smooth transition to a new
provider of digital certificates, especially since the customer may not have
anticipated the potential impact of such a clause when they first signed the
agreement.  I'm particularly concerned about this behavior because it seems
to be an abuse of the revocation system, and imposes costs on everyone who
is trying to generate accurate and efficient lists of revoked certificates
(e.g. Firefox).

 

I'm wondering what the Mozilla community thinks about such practices.

 

-Tim

 



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


RE: [FORGED] Re: How Certificates are Verified by Firefox

2019-12-04 Thread Tim Hollebeek via dev-security-policy
Someone really should write up "AIA chasing considered harmful".  It was
disputed at the TLS session at IETF 105, which shows that the reasoning
behind it is not as widely understood as it needs to be, even among TLS
experts.

I'm very appreciative of Firefox's efforts in this area.  Leveraging the
knowledge of all the publicly disclosed ICAs to improve chain-building is an
idea whose time has come.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Monday, December 2, 2019 3:29 PM
> To: Ben Laurie 
> Cc: mozilla-dev-security-policy
;
> Peter Gutmann 
> Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox
> 
> Why not "AIA chasing considered harmful"? The current state of affairs is
that
> most browsers [other than Firefox] will go and fetch the intermediate if
it's not
> cached. This manifests itself as sites not working in Firefox, and users
switching
> to other browsers.
> 
> You may be further dismayed to learn that Firefox will soon implement
> intermediate preloading [1] as a privacy-preserving alternative to AIA
chasing.
> 
> - Wayne
> 
> [1]
>
https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading
> #Intermediate_CA_Preloading
> 
> On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie  wrote:
> 
> >
> >
> > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann
> > 
> > wrote:
> >
> >> Ben Laurie via dev-security-policy
> >> 
> >> writes:
> >>
> >> >In short: caching considered harmful.
> >>
> >> Or "cacheing considered necessary to make things work"?
> >
> >
> > If you happen to visit a bazillion sites a day.
> >
> >
> >> In particular:
> >>
> >> >caching them and filling in missing ones means that failure to
> >> >present correct cert chains is common behaviour.
> >>
> >> Which came first?  Was cacheing a response to broken chains or broken
> >> chains a response to cacheing?
> >>
> >> Just trying to sort out cause and effect.
> >>
> >
> > Pretty sure if broken chains caused browsers to not show pages, then
> > there wouldn't be broken chains.
> >
> > --
> > I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
> > #VerifyAllTheThings.
> >
> > https://g.co/u58vjr https://g.co/adjusu *(Google internal)*
> >
> ___
> 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


RE: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Tim Hollebeek via dev-security-policy
I think “IETF does not define policy” is about as true as “individuals 
represent themselves at IETF.”  But that’s a longer rathole.

 

I also don’t think it’s helpful to try to redefine long-standing and 
well-understood terminology like what it means to issue a certificate.  In 
fact, I just checked, and using a definition like “reserving a serial number” 
causes many of the issuance requirements in RFC 5280 to be non-sensical.

 

It would be helpful for one of the relevant documents, or another document, or 
even an errata, to clarify that OCSP services can be offered for 
pre-certificates.  It’s merely a question of clarifying the technical 
requirements about how an OCSP service should operate, as those requirements 
currently can be read to not allow OCSP responses for non-certificates.

 

Not sure what reason there would be to oppose such a simple clarification that 
aligns the relevant requirements with the desired policy, especially since it 
is backwards compatible.

 

-Tim

 

From: Ryan Sleevi  
Sent: Thursday, September 19, 2019 2:17 PM
To: Tim Hollebeek 
Cc: Rob Stradling ; Alex Cohn ; 
mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 
; Jeremy Rowley 
Subject: Re: DigiCert OCSP services returns 1 byte

 

 

 

On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

I think that's fine as Mozilla and/or the CABF can and should override RFCs 
when it makes sense to do so, but I think it would also be helpful in the long 
term to fix the discrepancy, especially as CT is likely to be used in more 
certificate ecosystems in the future.

 

Isn't the core tenet that the IETF does not define policy? This seems very well 
rooted in policy, as you note.

 

The question does not seem to be about whether or not 
precertificates-are-certificates (and, in a -bis world, they're clearly a 
SignedData-thing-that-isn't), but what constitutes the act of issuance: is it 
signing a thing (whether a TBSCertificate or something other, like a 
precertificate under 6962 or 6962-bis)? Is it reserving the serial number and 
assigning it in the system?

 

In any event, if/when CT is used in other systems, they'll be using different 
CT logs, so they'll really be entirely different ecosystems. It seems that the 
policy management authority (i.e. the equivalent to browsers, in the Web PKI) 
for those ecosystems can provide clarity, and it further emphasizes why a 
single CA certificate should not participate in multiple PMAs, to reduce the 
risk of and avoid conflicts and/or misunderstandings.



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


RE: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Tim Hollebeek via dev-security-policy
> Thanks Wayne.  You're right.
>
> (I read the "SHOULD NOT" requirement, forgot it had been superseded, and
> didn't read further.  I wonder if it would be reasonable to remove the
> superseded requirement from the BRs now, given that it was superseded over
> 6 years ago?)

Removing out of date requirements was one of the things I did in my spring 
cleanup branch, but I don't know if I caught this one.  There's some even 
older, more obsolete text in there.

-Tim


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


RE: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Tim Hollebeek via dev-security-policy
Sorry for being unclear.

If the IETF goes the direction of "pre-certificates are not certificates", then 
we find ourselves in a world where the RFCs say that they should not get OCSP 
services, but Mozilla policy (and potentially the BRs) says that they should.

I think that's fine as Mozilla and/or the CABF can and should override RFCs 
when it makes sense to do so, but I think it would also be helpful in the long 
term to fix the discrepancy, especially as CT is likely to be used in more 
certificate ecosystems in the future.

Note that this doesn't mean that CT-bis has to state that pre-certificates are 
certificates, but it (or something later, or another draft ...) should at 
mention that OCSP responses for pre-certificates are allowed.

-Tim

> -Original Message-
> From: Rob Stradling 
> Sent: Monday, September 16, 2019 5:28 AM
> To: Tim Hollebeek 
> Cc: Jeremy Rowley ; Alex Cohn
> ; mozilla-dev-security-pol...@lists.mozilla.org; Wayne
> Thayer 
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On 13/09/2019 19:24, Tim Hollebeek wrote:
> > Yes, but I think this clarifies things in the wrong direction.
> 
> Hi Tim.  I'm not clear what you mean.
> 
> I was talking specifically and only about what IETF could/should do regarding
> this matter.  Which part did you disagree with, and why?
> 
> > -Tim
> >
> >> -Original Message-
> >> From: Rob Stradling 
> >> Sent: Friday, September 13, 2019 4:22 AM
> >> To: Tim Hollebeek ; Jeremy Rowley
> >> ; Alex Cohn 
> >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >> 
> >> Subject: Re: DigiCert OCSP services returns 1 byte
> >>
> >> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> >>> So, this is something that would be helpfully clarified via either
> >>> an IETF draft,
> >>
> >> There's already a 6962-bis draft [1] in IESG Last Call, which (when
> >> we finally complete it!) will obsolete RFC6962.  6962-bis redefines
> >> precertificates so that they're not actually X.509 certificates.
> >> Therefore, I don't think a "clarify RFC6962" draft is necessary.
> >>
> >> Thinking aloud...
> >> Does anything need to be clarified in 6962-bis though?
> >> A (non-X.509) 6962-bis precertificate contains the serial number that
> >> will appear in the certificate (if or when that certificate is
> >> issued),
> >> so: Should the CA be forbidden, permitted or required to operate
> >> revocation services for that serial number once the 6962-bis
> >> precertificate has been produced but before the certificate has been
> >> issued?  (And is this a technical matter for 6962-bis to address, or
> >> a policy matter that's out of scope for the 6962-bis document?)
> >>
> >>
> >> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> >>
> >>> or clarifications in the BRs.  There are various things in the OCSP
> >>> RFCs and
> >> even the BRs that can be read as precluding good OCSP responses for
> >> pre- certificates, although the situation is unclear since the
> >> relevant sections are blissfully ignorant of CT, and the correct
> >> behavior here was unfortunately left out of RFC 6962, which should have
> clarified this.
> >>>
> >>> Happy to help draft something.  There are some interesting
> >>> complexities
> >> once you dig deeper.
> >>>
> >>> -Tim
> >>>
> >>>> -Original Message-
> >>>> From: dev-security-policy
> >>>>  On Behalf Of Jeremy
> >>>> Rowley via dev-security-policy
> >>>> Sent: Thursday, September 12, 2019 1:46 PM
> >>>> To: Alex Cohn 
> >>>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >>>> 
> >>>> Subject: RE: DigiCert OCSP services returns 1 byte
> >>>>
> >>>> The language says you have to provide the response for the cert as
> >>>> if it exists, but the reality is that sending a response for the
> >>>> precert is the same as calculating the result for the certificate
> >>>> as if it exists and sending that. They are the same thing because
> >>>> the precert is treated the same as the final cert if the final cert 
> >>>> doesn’t
> exist.
> >>>>
> >>>> I believe the intent is that a CT-naïve OCSP checker would work
> >>>> normal

RE: DigiCert OCSP services returns 1 byte

2019-09-13 Thread Tim Hollebeek via dev-security-policy
Yes, but I think this clarifies things in the wrong direction.

-Tim

> -Original Message-
> From: Rob Stradling 
> Sent: Friday, September 13, 2019 4:22 AM
> To: Tim Hollebeek ; Jeremy Rowley
> ; Alex Cohn 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> 
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > So, this is something that would be helpfully clarified via either an
> > IETF draft,
> 
> There's already a 6962-bis draft [1] in IESG Last Call, which (when we finally
> complete it!) will obsolete RFC6962.  6962-bis redefines precertificates so 
> that
> they're not actually X.509 certificates.
> Therefore, I don't think a "clarify RFC6962" draft is necessary.
> 
> Thinking aloud...
> Does anything need to be clarified in 6962-bis though?
> A (non-X.509) 6962-bis precertificate contains the serial number that will
> appear in the certificate (if or when that certificate is issued),
> so: Should the CA be forbidden, permitted or required to operate revocation
> services for that serial number once the 6962-bis precertificate has been
> produced but before the certificate has been issued?  (And is this a technical
> matter for 6962-bis to address, or a policy matter that's out of scope for the
> 6962-bis document?)
> 
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> 
> > or clarifications in the BRs.  There are various things in the OCSP RFCs and
> even the BRs that can be read as precluding good OCSP responses for pre-
> certificates, although the situation is unclear since the relevant sections 
> are
> blissfully ignorant of CT, and the correct behavior here was unfortunately 
> left
> out of RFC 6962, which should have clarified this.
> >
> > Happy to help draft something.  There are some interesting complexities
> once you dig deeper.
> >
> > -Tim
> >
> >> -Original Message-
> >> From: dev-security-policy
> >>  On Behalf Of Jeremy
> >> Rowley via dev-security-policy
> >> Sent: Thursday, September 12, 2019 1:46 PM
> >> To: Alex Cohn 
> >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >> 
> >> Subject: RE: DigiCert OCSP services returns 1 byte
> >>
> >> The language says you have to provide the response for the cert as if
> >> it exists, but the reality is that sending a response for the precert
> >> is the same as calculating the result for the certificate as if it
> >> exists and sending that. They are the same thing because the precert
> >> is treated the same as the final cert if the final cert doesn’t exist.
> >>
> >> I believe the intent is that a CT-naïve OCSP checker would work
> >> normally when presented with a precert or a certificate. Afterall, a
> >> precert is really just a certificate with a special extension.
> >>
> >> From: Alex Cohn 
> >> Sent: Thursday, September 12, 2019 9:25 AM
> >> To: Jeremy Rowley 
> >> Cc: Wayne Thayer ; mozilla-dev-security-
> >> pol...@lists.mozilla.org
> >> Subject: Re: DigiCert OCSP services returns 1 byte
> >>
> >> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via
> >> dev-security-policy
> >> mailto:dev-security-
> >> pol...@lists.mozilla.org>> wrote:
> >> This means, for example, that (i) a CA must provide OCSP services and
> >> responses in accordance with the Mozilla policy for all
> >> pre-certificates as if corresponding certificate exists and (ii) a CA
> >> must be able to revoke a pre- certificate if revocation of the
> >> certificate is required under the Mozilla policy and the
> >> corresponding certificate doesn't actually exist and therefore cannot be
> revoked.
> >>
> >> Should a CA using a precertificate signing certificate be required to
> >> provide OCSP services for their precertificates? Or is it on the
> >> relying party to calculate the proper OCSP request for the final
> >> certificate and send that instead? In other words, should we expect a
> >> CT-naïve OCSP checker to work normally when presented, e.g., with
> https://crt.sh/?id=1868433277?
> >>
> >> Alex
> >> ___
> >> dev-security-policy mailing list
> >> dev-security-policy@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-security-policy
> >>
> >> ___
> >> 

RE: DigiCert OCSP services returns 1 byte

2019-09-13 Thread Tim Hollebeek via dev-security-policy
Tim Shirley did a good job of pointing it out.  The relevant OCSP RFCs talk 
about issued certificates, which pre-certificates aren’t.  This isn’t a policy 
matter, it’s a matter of a plain reading of the relevant RFCs, and trying to 
align that with what people want them to say as opposed to what they actually 
say.

 

Whatever the policy is, and I’m actually supportive of Wayne’s policy goals, 
the CT and OCSP RFCs actually have requirements that potentially contradict 
those goals, especially under some interpretations.

 

I’d like to fix the relevant requirements to allow to the policy that there 
seems to be a growing consensus for.

 

-Tim

 

From: Ryan Sleevi  
Sent: Thursday, September 12, 2019 6:44 PM
To: Tim Hollebeek 
Cc: Jeremy Rowley ; Alex Cohn ; 
mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 

Subject: Re: DigiCert OCSP services returns 1 byte

 

Without wanting to be antagonistic, I've come to learn I can count on you to 
suggest that X deserves clarification because it's ambiguous, but I've also 
learned I have trouble learning where the ambiguity exists or why. Recall that 
part of this confusion, regrettably, came from an earnest attempt to try and 
helpfully clarify the BRs with respect to precertificates, so I've come to view 
clarifications as just as much, if not more, risky than the original language.

 

The question about whether and how a pre-certificate is viewed is definitely a 
matter for policy, and so I'm definitely opposed to attempting to address it in 
IETF drafts, and somewhat opposed to clarifying it in the BRs, since really, 
it's a matter of policy.

 

Could you perhaps highlight which "various things in the OCSP RFCs" that might 
be read to conflict or preclude a good response? I think that's probably the 
best way to figure out what, where, is to understand how the interpretation 
came to be. It could be simply that the interpretation overlooked other 
sections, as we've seen in the past (e.g. with IP addresses in dNSName or with 
underscores), and so that seems like the best starting point.

 

On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

So, this is something that would be helpfully clarified via either an IETF 
draft, or clarifications in the BRs.  There are various things in the OCSP RFCs 
and even the BRs that can be read as precluding good OCSP responses for 
pre-certificates, although the situation is unclear since the relevant sections 
are blissfully ignorant of CT, and the correct behavior here was unfortunately 
left out of RFC 6962, which should have clarified this.

Happy to help draft something.  There are some interesting complexities once 
you dig deeper.

-Tim

> -Original Message-
> From: dev-security-policy  <mailto:dev-security-policy-boun...@lists.mozilla.org> > On
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, September 12, 2019 1:46 PM
> To: Alex Cohn mailto:a...@alexcohn.com> >
> Cc: mozilla-dev-security-pol...@lists.mozilla.org 
> <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; Wayne Thayer
> mailto:wtha...@mozilla.com> >
> Subject: RE: DigiCert OCSP services returns 1 byte
> 
> The language says you have to provide the response for the cert as if it 
> exists,
> but the reality is that sending a response for the precert is the same as
> calculating the result for the certificate as if it exists and sending that. 
> They are
> the same thing because the precert is treated the same as the final cert if 
> the
> final cert doesn’t exist.
> 
> I believe the intent is that a CT-naïve OCSP checker would work normally when
> presented with a precert or a certificate. Afterall, a precert is really just 
> a
> certificate with a special extension.
> 
> From: Alex Cohn mailto:a...@alexcohn.com> >
> Sent: Thursday, September 12, 2019 9:25 AM
> To: Jeremy Rowley  <mailto:jeremy.row...@digicert.com> >
> Cc: Wayne Thayer mailto:wtha...@mozilla.com> >; 
> mozilla-dev-security-
> pol...@lists.mozilla.org <mailto:pol...@lists.mozilla.org> 
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
>  <mailto:dev-security-policy@lists.mozilla.org> <mailto:dev-security- 
> <mailto:dev-security-> 
> pol...@lists.mozilla.org <mailto:pol...@lists.mozilla.org> >> wrote:
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as if
> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
> certificate if revocation of the certificate is required under the Mozilla 
> policy
> and the corre

RE: DigiCert OCSP services returns 1 byte

2019-09-12 Thread Tim Hollebeek via dev-security-policy
So, this is something that would be helpfully clarified via either an IETF 
draft, or clarifications in the BRs.  There are various things in the OCSP RFCs 
and even the BRs that can be read as precluding good OCSP responses for 
pre-certificates, although the situation is unclear since the relevant sections 
are blissfully ignorant of CT, and the correct behavior here was unfortunately 
left out of RFC 6962, which should have clarified this.

Happy to help draft something.  There are some interesting complexities once 
you dig deeper.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, September 12, 2019 1:46 PM
> To: Alex Cohn 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> 
> Subject: RE: DigiCert OCSP services returns 1 byte
> 
> The language says you have to provide the response for the cert as if it 
> exists,
> but the reality is that sending a response for the precert is the same as
> calculating the result for the certificate as if it exists and sending that. 
> They are
> the same thing because the precert is treated the same as the final cert if 
> the
> final cert doesn’t exist.
> 
> I believe the intent is that a CT-naïve OCSP checker would work normally when
> presented with a precert or a certificate. Afterall, a precert is really just 
> a
> certificate with a special extension.
> 
> From: Alex Cohn 
> Sent: Thursday, September 12, 2019 9:25 AM
> To: Jeremy Rowley 
> Cc: Wayne Thayer ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> mailto:dev-security-
> pol...@lists.mozilla.org>> wrote:
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as if
> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
> certificate if revocation of the certificate is required under the Mozilla 
> policy
> and the corresponding certificate doesn't actually exist and therefore cannot
> be revoked.
> 
> Should a CA using a precertificate signing certificate be required to provide
> OCSP services for their precertificates? Or is it on the relying party to 
> calculate
> the proper OCSP request for the final certificate and send that instead? In
> other words, should we expect a CT-naïve OCSP checker to work normally
> when presented, e.g., with https://crt.sh/?id=1868433277?
> 
> Alex
> ___
> 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


RE: CA handling of contact information when reporting problems

2019-08-22 Thread Tim Hollebeek via dev-security-policy
DigiCert currently has a policy of not publishing the names of those who
report things to us without their permission.  It just seems like the right 
thing to do.

If we do find that people are abusing that protection to selectively harass 
people that they personally have issues with, we may need to revisit that, but 
we haven't seen any evidence that is currently happening.  Most of the people 
who report issues to us are quite professional about it, and we're always happy 
to engage with them.

I would be interested to hear what others think the appropriate behavior for a 
CA is here, since it isn't covered by any compliance requirements.  

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Jakob Bohm via dev-security-policy
> Sent: Monday, August 19, 2019 8:22 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: CA handling of contact information when reporting problems
> 
> On 20/08/2019 03:15, Corey Bonnell wrote:
> > On Monday, August 19, 2019 at 10:26:06 AM UTC-4, Mathew Hodson wrote:
> >> Tom Wassenberg on Twitter reported an experience he had with Sectigo
> >> when reporting a compromised private key.
> >>
> >> https://twitter.com/tomwas54/status/1162114413148725248
> >> https://twitter.com/tomwas54/status/1162114465065840640
> >> https://twitter.com/tomwas54/status/1162114495017299976
> >>
> >> "So a few weeks ago, I came across a private key used for a TLS
> >> certificate, posted online. These should never be public (hence the
> >> "private"), and every trusted CA is obliged to revoke any certificate
> >> they issued when they become aware its private key is compromised.
> >>
> >> "So when I informed the issuing CA (@SectigoHQ) about this, they
> >> promptly revoked the cert. Two weeks later however, I receive an
> >> angry email from the company using the cert (cc'd to their lawyer),
> >> blaming me for a disruption in the services they provide.
> >>
> >> "The company explicitly mentioned @SectigoHQ "was so kind" to give
> >> them my contact info! It was a complete surprise for me that
> >> @SectigoHQ would do this without my consent. Especially seeing how
> >> the info was used to badger me."
> >>
> >> If these situations were common, it could create a chilling effect on
> >> problem reporting that would hurt the WebPKI ecosystem. Are specific
> >> procedures and handling of contact information in these situations
> >> covered by the BRs or Mozilla policy?
> >
> > Many CAs disclose the reporter's name and email address as part of their
> response to item 1 of the incident report template [1]. So this information is
> already publicly available if the Subscriber were so inclined to look for it.
> >
> > Section 9.6.3 of the BRs list the provisions that must be included in the
> Subscriber Agreement that every Applicant must agree to. Notably, one of
> them is protection of the private key. The Subscriber in this case materially
> violated the Subscriber Agreement by disclosing their private key, so I don't
> think they have much footing to go badgering others for problems that they
> brought on themselves.
> >
> > Thanks,
> > Corey
> >
> > [1]
> > https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
> >
> 
> The question was if this is appropriate behavior, when the incident is not at
> the CA, but at a subscriber.  This is typically different from the case of 
> security
> researchers filing systemic CA issues for which they typically want public
> recognition.
> 
> Specificially, the question is one of whistleblower protection for the 
> reporter
> (in the general sense of whistleblower protection, not that of any single
> national or other whistleblower protection legal regime).
> 
> On the other hand there is the question of subscribers having a right to face
> their accuser when there might be a question of trust of subjectivity 
> (example:
> Someone with trusted subscriber private key access maliciously sending it to
> the CA to cause revocation for failure to protect said key).
> 
> Situation would get much more complicated when the report is one of
> claiming a subscriber violates a subjective rule, such as malicious cert use 
> or
> name ownership conflicts.
> 
> 
> 
> 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


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


RE: Use of Certificate/Public Key Pinning

2019-08-22 Thread Tim Hollebeek via dev-security-policy
So, pinning is an extremely complicated topic that I've always wanted to write 
a blog post about, but have never had the time to do it.  It happens fairly 
regularly that we have to assist a company that has painted themselves into a 
corner with a poorly thought out pinning scheme.

In my experience, it's mostly bad implementations of pinning that cause most of 
the problems, not pinning itself.  I've seen people pin leaf certificate serial 
numbers, for example.  That's guaranteed to end badly.

If you do feel the need to pin, please make sure you've thought through all the 
possible certificate replacement use cases and make sure you have designed, 
implemented, AND TESTED them to make sure they work.

All too often, a customer complains things stop working when they replace their 
certificate ... but no one at the company is aware what exactly is being pinned 
or why.

Use pinning with care.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, August 14, 2019 2:08 PM
> To: Nuno Ponte 
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: Use of Certificate/Public Key Pinning
> 
> On Tue, Aug 13, 2019 at 11:12 AM Nuno Ponte via dev-security-policy < dev-
> security-pol...@lists.mozilla.org> wrote:
> 
> > Dear m.d.s.p.,
> >
> > I would like to bring into discussion the use of certificate/public
> > key pinning and the impacts on the 5-days period for certificate
> > revocation according to BR §4.9.1.1.
> >
> > Recently, we (Multicert) had to rollout a general certificate
> > replacement due to the serial number entropy issue. Some of the most
> > troubled cases to replace the certificates were customers doing
> > certificate pinning on mobile apps. Changing the certificate in these
> > cases required configuration changes in the code base, rebuild app, QA
> > testing, submission to App stores, call for expedited review of each
> > App store, wait for review to be completed and only then the new app
> > version is made available for installation by end users (which is turn
> > are required to update the app the soonest).
> >
> > Meeting the 5-days deadline with this sort of process is
> > “challenging”, at best.
> >
> > A first approach is to move from certificate pinning to public key
> > pinning (PKP). This prevents the need to update the app in many of the
> > certificate replacement operations, where the public key is reused and
> > the certificate can be replaced transparently to the app (generically, an
> “User Agent”
> > doing PKP).
> >
> > However, in the event of a serious security incident that requires
> > re-key (such as key compromise), the certificate must be revoked in
> > less than 24 hours (for the benefit of everyone – subscriber, relying
> > parties, issuing CA, etc). It’s virtually impossible to release a new
> > app version within this timeframe. And this, I think, make a very
> > strong point against the use of PKI.
> >
> > On the other side, PKP is a simple yet powerful and effective
> > technique to protect against MITM and other attacks. It seems to be
> > widely used in apps with advanced threat models (mobile banking,
> > sensitive personal information, etc) and there are many frameworks
> > available (including native support in Android via Network Security
> Configuration [1]).
> >
> > There are several possible mitigation actions, such as pinning more
> > than one public key to have more than one certificate to quickly
> > rollover in case of a revocation. Even then, it is very likely that
> > all the redundant key pairs were generated and maintained by the same
> > systems and procedures, and thus all of them will become effectively
> compromised.
> >
> > Ultimately, it may become common practice that 1) PKP frameworks are
> > set to bypass revocation checks or 2) PKP is done with private
> > certificates (homemade, self-signed, managed ad-hoc with no CRL/OCSP
> > services). Does any of this leads to a safer Internet?
> >
> > I don’t expect this thread to end up into an absolute conclusion
> > advocating for or against, but opening it to discussion and
> > contributions may help to document possible strategies, mitigations,
> > alternatives, pros & cons, and hopefully provide guidance for an educated
> decision.
> >
> > Best regards,
> >
> > Nuno Ponte
> > Multicert SA
> >
> 
> Nuno,
> 
> Thanks for raising this. I appreciate that a CA is attempting to provide 
> guidance
> to their Subscribers, since, as you note, the CA is still beholden to the 
> Baseline
> Requirements, and the Subscriber still beholden to their Subscriber
> Agreement.
> 
> As one of the co-authors of the HTTP Public Key Pinning RFC, RFC 7469, I would
> readily encourage your Subscribers not to pin at all. However, if they are 
> going
> to pin to anything, then it:
> 1) Should be to the public key, not certificate
> 2) Should only be to the root
> 3) Should require an agreement with the root that the Root (i.e. Multicert) 

RE: Incident Report - Entrust Datacard issued certificates with the incorrect Organization Name

2019-03-15 Thread Tim Hollebeek via dev-security-policy
What is the rationale for waiting until March 20th for revocation given that
the issue was noticed on March 7th?

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Bruce via dev-security-policy
> Sent: Friday, March 15, 2019 4:59 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Incident Report - Entrust Datacard issued certificates with the
> incorrect Organization Name
> 
> On March 7, 2019, Entrust Datacard discovered that SSL certificates with
the
> wrong Organization value were issued to a customer. The investigation was
> completed 15 March 2019.
> 
> Details of the incident report can be found here,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1535735.
> 
> All certificates will be revoked by 20 March 2019.
> 
> Thanks, Bruce.
> ___
> 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


RE: Possible DigiCert in-addr.arpa Mis-issuance

2019-02-27 Thread Tim Hollebeek via dev-security-policy

> On 27/02/2019 00:10, Matthew Hardeman wrote:
> > Is it even proper to have a SAN dnsName in in-addr.arpa ever?
> >
> > While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it
> > rarely has anything other than PTR and NS records defined.
> >
>
> While there is no current use, and the test below was obviously somewhat
> contrived (and seems to have triggered a different issue), one cannot rule 
> out
> the possibility of a need appearing in the future.

At least the last time this came up a few years ago, there were actually a 
significant number of webservers running under in-addr.arpa, with Comodo and 
LE certificates (as well as a handful of others).  I believe Corey posted a 
list.

Exactly what they were doing there is an open question, and when I asked, no 
one responded.  I'm still very curious as to why some people seem to actually 
be running servers there, or if it's just a side-effect of misconfigured 
CNAMEs causing them to appear to be there, or similar.

-Tim


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


RE: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

2019-01-25 Thread Tim Hollebeek via dev-security-policy

> On 2019-01-24 20:19, Tim Hollebeek wrote:
> > I think the assertion that the commonName has anything to do with what
> > the user would type and expect to see is unsupported by any of the
> > relevant standards, and as Rob noted, having it be different from the
> > SAN strings is not in compliance with the Baseline Requirements.
> 
> The BR do not say anything about it.

Rob already quoted it: "If present, this field MUST contain a single IP
address 
or Fully-Qualified Domain Name that is one of the values contained in the 
Certificate's subjectAltName extension".

The only reason it's allowed at all is because certain legacy software 
implementations would choke if it were missing.

> > Requiring translation to a U-label by the CA adds a lot of additional
> > complexity with no benefit.
> 
> I have no idea what is so complex about that. When generating the
> certificate, it's really just calling a function. On the other hand, when
reading
> a certificate you have to guess what they did.

Given that it has no benefit at all, any complexity is too much.  As I
mentioned
above, its existence is merely a workaround for a bug in obsolete software.

> And if it's really to complex, just remove the CN, or is that too complex
too?

See above.

> > What users type and see are issues that are best left to Application
> > Software Suppliers (browsers).
> 
> So you're saying all the other software that deals with certificates
should
> instead add complexity?

What they actually do is to ignore this obsolete field, and process the 
subjectAltNames.  There's no additional complexity for them because
they already are doing the conversion of IDN names.

-Tim



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


RE: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

2019-01-24 Thread Tim Hollebeek via dev-security-policy
I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is 
not in compliance with the Baseline Requirements.  It's also deprecated.  If 
anything, it should cease to exist.

Requiring translation to a U-label by the CA adds a lot of additional complexity
with no benefit.

What users type and see are issues that are best left to Application Software
Suppliers (browsers).

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Kurt Roeckx via dev-security-policy
> Sent: Thursday, January 24, 2019 4:04 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded
> international domain names
> 
> On 2019-01-24 9:47, Buschart, Rufus wrote:
> > Good morning!
> >
> > I would like to sharpen my argument from below a little bit: If a CA gets a
> request to issue a certificate for the domain xn--gau-7ka.siemens.de, how
> can the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not
> only a very strange server name? At least I don't have a glass bowl to read
> the mind of my customers. Therefor I would say, it is perfectly okay to issue
> a certificate for xn--gau-7ka.siemens.de as long as you perform a successful
> domain validation for xn--gau-7ka.siemens.de.
> 
> Will you fill something in in the commonName? I think what is expected in
> the commonName is what the user would type and expect to see, I don't
> think the commonName should contain xn--gau-7ka.siemens.de. If you have
> a commonName, I would expect that it contains gauß.siemens.de. And if you
> create a commonName then, you are required to check that it matches the
> xn--gau-7ka.siemens.de in the SAN.
> 
> 
> Kurt
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/36Cdb8NdVuWoSCnRVsmajRE7Vc?u=https
> %3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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


RE: AlwaysOnSSL web security issues

2019-01-16 Thread Tim Hollebeek via dev-security-policy
Here's the article we published on this subject a while ago:

https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practices/

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, January 10, 2019 4:47 PM
> To: Wayne Thayer 
> Cc: Alex Cohn ; Alex Gaynor ;
> mozilla-dev-security-pol...@lists.mozilla.org; Buschart, Rufus
> ; Hanno Böck 
> Subject: RE: AlwaysOnSSL web security issues
> 
> Yes – we will do so. We’ve encouraged all customers to not generate key
> pairs for TLS certs on behalf of third parties in the past. A reminder would 
> be
> useful.
> 
> From: Wayne Thayer 
> Sent: Thursday, January 10, 2019 1:18 PM
> To: Jeremy Rowley 
> Cc: Alex Gaynor ; Buschart, Rufus
> ; Alex Cohn ; Hanno
> Böck ; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: AlwaysOnSSL web security issues
> 
> Thanks Jeremy. The fact that CertCenter is just a reseller and not an RA was
> not obvious to me. To your point, building an insecure website on top of a
> CA's API does not strike me as something that we should be terribly worried
> about.
> 
> I would encourage DigiCert to ask CertCenter to discontinue the practice of
> generating private keys for their customers.
> 
> - Wayne
> 
> On Thu, Jan 10, 2019 at 11:00 AM Jeremy Rowley via dev-security-policy
> mailto:dev-security-
> pol...@lists.mozilla.org>> wrote:
> A couple of thoughts:
> 1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted
> and operated by DigiCert. All validation, issuance, and linting is performed 
> by
> DigiCert prior to issuance.
> 2) Lots of cert customers have insecure websites. This indicates CAs should
> scan websites for vulnerabilities. If that's the case, there will be lots of
> revocations and that needs to be built into the Mozilla policy if required.
> 3) The only way we know that CertCenter is a reseller is by 
> self-identification.
> They use the same issuance and validation system as all other customers. If
> they didn't self-identify as a reseller, they could do the same thing and look
> like an enterprise.
> 4) I think they took their website down once the vulnerability was reported.
> We've asked them to fix the site because it's high profile. However, if the
> customer was something like Mozilla or Google, would we demand
> revocation of their certificates? Granted, they wouldn't have the same
> vulnerabilities, but I'm having a hard time differentiating from the CA
> perspective.
> 5) Generating private keys for third parties is definitely NOT encouraged by
> DigiCert.
> 
> Anyway, I'm not sure what do here as it seems like the main difference
> between this and any other insecure website is how they self-identify.
> 
> Jeremy
> 
> -Original Message-
> From: dev-security-policy  boun...@lists.mozilla.org boun...@lists.mozilla.org>> On Behalf Of Alex Gaynor via dev-security-
> policy
> Sent: Thursday, January 10, 2019 7:10 AM
> To: Buschart, Rufus
> mailto:rufus.busch...@siemens.com>>
> Cc: Alex Cohn mailto:a...@alexcohn.com>>; mozilla-
> dev-security-policy@lists.mozilla.org pol...@lists.mozilla.org>; Hanno Böck
> mailto:ha...@hboeck.de>>
> Subject: Re: AlwaysOnSSL web security issues
> 
> The Mozilla policy does not prohibit backdating, except when it's used to
> evade time-based policy controls.
> 
> Backdating certs by a few hours is a relatively common practice to minimize
> breakages for consumers with busted clocks.
> 
> Alex
> 
> On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy <
> dev-security-policy@lists.mozilla.org pol...@lists.mozilla.org>> wrote:
> 
> >  The certificate [1] seems also to be 'back-dated' by about 18 hours.
> > What is Mozillas opinion about this in the light of
> > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdat
> > ing_the_notBefore_Date
> > ?
> >
> > > It appears AlwaysOnSSL is not completely disabled - if we trust CT
> > > as a
> > timestamping service, [1] was issued after Hanno's email.
> > [...]
> > > [1] https://crt.sh/?id=1097197338
> > [...]
> > > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy <
> > dev-security-policy@lists.mozilla.org pol...@lists.mozilla.org>> wrote:
> > > >
> > > > Hi,
> > > >
> > > > AlwaysOnSSL was a free certificate authority operated by CertCenter.
> > > > I recently noticed that their main webpage was gone, but pieces of
> > > > the service were still online.
> > > > I immediately found a few web security issues. I reported those to
> > > > certcenter and digicert (which is the root CA their intermediate
> > > > chains to).
> > [...]
> > > > In response to this the service was completely disabled.
> > [...]
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org

RE: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

2018-12-18 Thread Tim Hollebeek via dev-security-policy
The problem is that the attackers get to choose the CA they use, so
multi-perspective validation doesn't provide any benefits unless everyone
has to do it.

I brought it up several times at the validation working group and as a
discussion topic at the Shanghai face to face, but unfortunately there
doesn't seem to be much enthusiasm for requiring it.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Rob Stradling via dev-security-policy
> Sent: Tuesday, December 18, 2018 7:42 AM
> To: Wayne Thayer 
> Cc: Ryan Sleevi ; mar...@marcan.st; mozilla-dev-security-
> policy 
> Subject: Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable
> 
> On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:
> 
> > I think it;s worth calling out that Let's Encrypt has implemented what
> > appears to be a relatively simple mitigation:
> > https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-b
> > ytes/77945
> 
> Sectigo implemented this same mitigation about a month ago.
> 
> > I am also interested to know if other CAs are considering this or
> > other mitigations (e.g. multi-perspective validation) for this attack.
> 
> Multi-perspective validation is something we've started to think about
too.
> 
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
> 
> ___
> 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


RE: Violation report - Comodo CA certificates revocation delays

2018-12-17 Thread Tim Hollebeek via dev-security-policy
I don't think we've commented on this before, but I'll note that sending an
e-mail
from the e-mail address listed as the contact address on a website is not
one of
the approved methods of showing ownership or control of a website as
specified
in section 3.2.2.4.  The approved methods of validating ownership or control

have undergone a lot of scrutiny, and the CA/Browser Forum continues to
spend
lots of its time trying to make them better.

Given the degree to which support and infrastructure is outsourced these
days,
it is tempting to say that merely comparing email addresses is a very, very
bad
way of confirming authenticity of requests and CAs should not rely on it.  
Technical measures like SPF or DMARC do not mitigate the risk that the
sender
is not authorized to request revocation as they do not verify that the
sender 
owns or controls the website that they are listed as the contact address
for.  
CAs should not accept that as proof of ownership or control, and I'm happy
that 
we didn't.

That said, the latest Baseline Requirements include Relying Parties as
someone
who can request revocation in section 4.9.2, in addition to "other third
parties".
This is basically anyone who has ever used a browser, which at this point is

most of the people on the planet.  I'm not sure why we don't just say
"anyone
can submit a Certificate Problem Report", because it's functionally
equivalent
(and much less confusing).  We take these requests very seriously, no matter
who they come from, and would encourage other CAs to do so as well.

Handling revocation requests within the mandated window is often very
challenging, but it's also very important to get right.  The recent
clarifications
and improvements from Wayne's ballot do make things significantly better,
but this is still an area we should pay close attention to in order to make
sure
we get the balance right in making sure revocations happen quickly,
efficiently,
and most importantly, securely when they are necessary.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of please please via dev-security-policy
> Sent: Monday, December 17, 2018 5:51 PM
> To: Wayne Thayer 
> Cc: MDSP 
> Subject: Re: Violation report - Comodo CA certificates revocation delays
> 
> A lot of things changes in 3 months it seems. ??
> 
> The wording for the new "validation of domain authorization or control
[...]
> should not be relied upon" condition seems open to interpretation, so I'm
> not sure if it really applies here. Wouldn't it fully cover the "no longer
legally
> permitted" condition as well in this case, making the latter redundant?
> 
> In any case, I should point out that even when taking into account the
latest
> version of the BRs instead of the one that applied at the time (v.1.6.0),
it
> would still have violated the "no longer legally permitted" condition that
I
> previously quoted within the extended deadline of 5 days anyway.
> 
> Thanks again Wayne for the follow-up!
> 
> Guillaume Fortin-Debigaré
> 
> 
> 
> From: Wayne Thayer 
> Sent: December 17, 2018 13:00
> To: please please
> Cc: MDSP
> Subject: Re: Violation report - Comodo CA certificates revocation delays
> 
> On Sun, Dec 16, 2018 at 11:49 PM please please
> mailto:pleaseiwantt...@hotmail.com>>
> wrote:
> I just noticed that Comodo CA has finally posted its incident report in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
> 
> Comments:
> - The report suggests that no BR violation occurred because I was not the
> Subscriber to fulfill the conditions in bullet point 1 of BR 4.9.1.1.
However, I
> believe I fulfilled the conditions for triggering the 24 hours revocation
> anyway because of bullet point 6 of the same BR, which states "The CA is
> made aware of any circumstance indicating that use of a Fully Qualified
> Domain Name or IP address in the Certificate is no longer legally
permitted
> (e.g. [...] a relevant licensing or services agreement between the Domain
> Name Registrant and the Applicant has terminated [...])", as I explicitly
stated
> in my initial revocation request email that Cloudflare was no longer
> authorized to represent my domain but still controlled the private keys.
> 
> Sectigo's (formerly Comodo's) response does seem to both admit the
> violation and downplay it. Shortly after the violation the BRs were
changed
> to allow 5 days for most revocations, and that may be the motivation for
> calling out that the Subscriber didn't request revocation. However, I
believe
> this case still falls under the 24-hour rule due to 4.9.1.1(4):
> 
> The CA obtains evidence that the validation of domain authorization or
> control for any Fully-Qualified Domain Name or IP address in the
Certificate
> should not be relied upon.
> 
> - Comodo CA claims that my request was "potentially ambiguous", but did
> not explain in what regard, nor did they ever asked me for clarifications.
I
> can only assume as of now that the issue was to get an e

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-24 Thread Tim Hollebeek via dev-security-policy
That may be true, but I don't see any upside for using that date.  If you need
to make a minor CPS update in early January for any reason, you now have
additional work.

I think late December policy changes should be avoided as a general rule.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Wednesday, October 24, 2018 9:44 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Jakob Bohm 
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
> 
> On 24/10/2018 00:08, Tim Hollebeek wrote:
> > I agree with you, but December 31 is a particularly horrible compliance
> deadline.  Perhaps January 31?
> >
> 
> Note that the requirement applies only to CP/CPS dated after that date.
> So it is really Dec 31 + the time until the CP/CPS is updated for some other
> reason.  This is different than many other policy requirements, and a
> welcome reduction in administrative overhead for all concerned (including
> root programs and relying parties).
> 
> For example, it a CA updated their CP/CPS in August 2018 to comply with
> new BRs, and again in May 2019 due to annual review, they need not comply
> until May 2019.
> 
> >
> >> -Original Message-
> >> From: dev-security-policy
> >>  On Behalf Of Wayne
> >> Thayer via dev-security-policy
> >> Sent: Monday, October 22, 2018 6:00 PM
> >> To: Kathleen Wilson 
> >> Cc: mozilla-dev-security-policy
> >> 
> >> Subject: Re: What does "No Stipulation" mean, and when is it OK to
> >> use it in CP/CPS?
> >>
> >> Having given this some more thought, I suggest the following changes:
> >>
> >> ...
> >>
> >> * Finally, I think we need some effective date for these as required
> practices.
> >> One approach would be to require compliance for any CP/CPS dated
> >> after Dec 31, 2018.
> >>
> >> - Wayne
> >>
> >> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via
> >> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >>
> >>> I have updated the section as follows:
> >>> - Removed the sentence that was trying to limit the use of "No
> >>> Stipulation". Hopefully the clarification about what these words
> >>> mean is sufficient.
> >>> - Added bullet points
> >>> - Added "Sections MUST not be left blank. ..."
> >>>
> >>>
> >>>
> >> https://clicktime.symantec.com/a/1/Xh-
> rJgK1XipLGMs1U1jQtvScEL4FB3RgBJ
> >> dwBJwZeYE=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7
> >> UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9
> >> bhkXphYgKSUVtoR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82r
> >>
> k0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiPxVGtBuabizQhhSJTxJOnwKO
> WaoM-
> >> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMG
> >>
> HVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDXpcevjD2CbeA2U9
> QfVhB_kA
> >> _fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=htt
> >>
> ps%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Pract
> ices%
> >> 23CP.2FCPS
> >>> _Structured_According_to_RFC_3647
> >>>
> >>>
> >>> I continue to appreciate your feedback on this new section.
> >>>
> 
> 
> Enjoy
> 
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.
> https://clicktime.symantec.com/a/1/wiu9LnSxIGejJD4uoZpqluwf3s5JsQkbpA
> XBO8_i0rw=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=https%3A%2F%2F
> 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://clicktime.symantec.com/a/1/iMWW4Dv3PtBKTbZjlKIU-
> irUZprQKCSffpbwg_M87H8=?d=vW4rM0CTwt8BO-
> WkB0mRKJ4JerYClzYhMZEWRTwXeQpnsTE59W7amFJ7UBJ2Lqfz4GYYK9b1-
> 861DyJ4DaHeghkm5uPyaLz88lMhRqvIqIqTZA_cIJj019oR2rEK9bhkXphYgKSUV
> toR8Jv4c4ZyzmC1PwABos85PgNWZUQJmHU-
> PUFpXdUPJHpMF3mizDn82rk0Y2RsTkEa8rivnT6E8_XY2ct_Qb2EyuqdHD5BaiP
> xVGtBuabizQhhSJTxJOnwKOWaoM-
> G1uz_LEZUDTl53vgLqwOnLWYb8q3kLP7q7clVFhkAPULAOQGVhob01XI-
> oCmWpmJtDsMGHVzmozw0E1T4208EZyfyv2L2nQKYOsdTwEScupt4ut18MDX
> pcevjD2CbeA2U9QfVhB_kA_fCU3vcSLkeOXiJOLq-
> YfSsXuiLvEqqmw4GLGR758pQeOj_rVwNE30jDvfqbbmg&u=https%3A%2F%2Fl
> ists.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.moz

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-23 Thread Tim Hollebeek via dev-security-policy
I agree with you, but December 31 is a particularly horrible compliance 
deadline.  Perhaps January 31?

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Monday, October 22, 2018 6:00 PM
> To: Kathleen Wilson 
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
> 
> Having given this some more thought, I suggest the following changes:
> 
> * Forbid "no stipulation" altogether. While there are a few sections where it
> would be convenient to use "No stipulation" (e.g. 4.2.3 Time to Process
> Certificate Applications), I don't see a requirement for more descriptive
> language to be much of a burden (e.g. 4.2.3 could simply state: "we process
> applications in a commercially reasonable time but do not publish specific
> SLAs"). In the case of a CP that delegates requirements to one or more CPSs, 
> it
> is also more informative to state "Refer to CPS section" than to use "No
> stipulation". Finally, if we continue to allow "No stipulation", we really 
> won't
> know if a CA is aware of this discussion and is using the term properly.
> 
> * Section 1.1 of the BRs describes the reason that some sections are left
> blank:
> 
> In accordance with RFC 3647 and to facilitate a comparison of other 
> certificate
> policies and CPSs (e.g. for policy mapping), this document includes all 
> sections
> of the RFC 3647 framework. However, rather than beginning with a “no
> stipulation” comment in all empty sections, the CA/Browser Forum is leaving
> such sections initially blank until a decision of “no stipulation” is made.
> Some of the blank sections also cover important information (e.g. 3.3.1
> Identification and Authentication for Routine Re-key). We shouldn't allow "No
> stipulation" for these either.
> 
> * Add a requirement that language that only applies to certificates that are
> out-of-scope for Mozilla policy must be clearly marked as such. Many CP/CPSs
> cover document signing and other certificate usages, but they often aren't
> explicit about policies that aren't permitted for TLS and/or email 
> certificates.
> For example, it's permissible for a CP/CPS to describe procedures for
> certificate suspension in 4.9.15, but it should clearly state that suspension 
> will
> not be used with TLS certificates.
> 
> * Finally, I think we need some effective date for these as required 
> practices.
> One approach would be to require compliance for any CP/CPS dated after Dec
> 31, 2018.
> 
> - Wayne
> 
> On Tue, Oct 23, 2018 at 2:25 AM Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I have updated the section as follows:
> > - Removed the sentence that was trying to limit the use of "No
> > Stipulation". Hopefully the clarification about what these words mean
> > is sufficient.
> > - Added bullet points
> > - Added "Sections MUST not be left blank. ..."
> >
> >
> >
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS
> > _Structured_According_to_RFC_3647
> >
> >
> > I continue to appreciate your feedback on this new section.
> >
> > Thanks,
> > Kathleen
> >
> >
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> 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


RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-19 Thread Tim Hollebeek via dev-security-policy
I think blank sections should be disallowed.  The entire purpose of "No 
stipulation" is to make it clear that the omission of content was intentional.

With regards to some of these sections being useful, I agree that a good CPS 
contains more than the minimum content required from the BRs.  I personally 
view the use of a "minimal CPS" (lightly modified version of the BRs) by some 
organizations as a cause for concern.  From the discussion at CABF Shanghai, it 
sounds like many people share my concern.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Joanna Fox via dev-security-policy
> Sent: Friday, October 19, 2018 1:39 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
> 
> On Thursday, October 18, 2018 at 5:47:14 PM UTC-7, Jakob Bohm wrote:
> > On 15/10/2018 20:01, Kathleen Wilson wrote:
> > > I have added the following section to the Required Practices wiki page:
> > >
> > >
> https://clicktime.symantec.com/a/1/7p3XgkAIErb9F2a7I0h79owDFBAc5ICeK
> > > jHbhT4MfRQ=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5
> > > faQ8DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_
> > >
> O0TIYHZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJk
> mVn4u
> > >
> HGorLgZriWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHr
> kv4ynQk
> > > rYfWuuUGTWbKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-
> YKf2C3IkEFjzQ1KM07-g
> > > 8GY5W2f-
> L8l3AVEwYckAMj7BuG5f3ZntpsITX9xYav31NhE_3hQCFHyuuoC89KtOt1cq
> > > -
> 0hOXZSjQMhd9U8HPl2InCYHhLLGeW2jqa_qXR5wk2SwKC9ecK3MSN7EWKQ7Z
> FNQGGj8
> > >
> 9SqBMmPojMgjHEhA%3D%3D&u=https%3A%2F%2Fwiki.mozilla.org%2FCA%2
> FRequi
> > >
> red_or_Recommended_Practices%23BR_Commitment_to_Comply_statement
> _in_
> > > CP.2FCPS
> > >
> > > I will continue to appreciate feedback on this update.
> > >
> > > Thanks,
> > > Kathleen
> > >
> >
> > Upon closer look, it appears that most of the "No Stipulation" entries
> > in the BRs are things for which Mozilla would probably want explicit
> > statements, even though there are no specific BR requirements.
> >
> > For example:
> >
> > 1.5.1 Organization Administering this document (CP/CPS)
> > 1.5.3 Person Determining CPS suitability for the Policy
> > 1.5.4 CPS Approval procedures
> > 4.3.2 (Mostly relevant to customer relationship)
> > 4.4.1 (Only relevant to customer relationship)
> > 4.4.2 Publication of the certificate by the CA
> > 4.4.3 Notification of certificate issuance by the CA to other entities
> >(This would cover CT or other mechanisms suitable for CRLset
> > generation by Mozilla).
> > 4.5.2 Relying party public key and certificate usage
> >(This would typically cover disclaiming responsibility if users turn
> >off revocation checking or interpret the certificate as meaning
> >something other than a proof of identity of the private key holder).
> > 4.6 CERTIFICATE RENEWAL
> >This has been the subject of many discussions about appropriateness of
> >CA procedures.
> >   Except:
> > 4.6.4 (Mostly relevant to customer relationship)
> > 4.6.5 (Only relevant to customer relationship)
> > 4.7 CERTIFICATE RE-KEY
> >This has been the subject of many discussions about appropriateness of
> >CA procedures.
> >   Except:
> > 4.7.4 (Mostly relevant to customer relationship)
> > 4.7.5 (Only relevant to customer relationship)
> > 4.8 CERTIFICATE MODIFICATION
> >This has much relevance to situations of later discoveries of
> > discrepancies of changes in circumstances.  It is a recurring theme in
> > discussions about revoking such certificates.
> >   Except:
> > 4.8.4 (Mostly relevant to customer relationship)
> > 4.8.5 (Only relevant to customer relationship)
> > 4.9.4 Revocation Request Grace Period
> > 4.9.6 Revocation Checking Requirements for Relying Parties
> >This interacts closely with the features implemented in Mozilla products.
> > 4.9.8 Maximum Latency for CRLs
> > 4.10.3 Optional Features (for certificate status services)
> >This would for example indicate if the OCSP servers provide ways to
> > distinguish OCSP status for a real certificate and a fake certificate
> > with the same serial number.  If there are OCSP privacy features etc.
> > 4.11 (Mostly relevant to customer relationship)
> > 4.12 Key escrow and recovery policy and practices
> >This is the subject of a Mozilla requirement (not to provide such).
> >
> >
> >
> > Enjoy
> >
> > Jakob
> > --
> > Jakob Bohm, CIO, Partner, WiseMo A/S.
> >
> https://clicktime.symantec.com/a/1/qg1xJznChxmyUV0biuQ9q261sKYl0pswb3
> 9
> > gsDU-SoA=?d=L_e81rE8kYCYgIlLjCzed5rAyhZvhU9-
> WfrdxJja_havwHFfcaC7Z5faQ8
> > DCy5VncpZl1CphyvBJ8dTo3Ml-RY9dLRX4wfNVPbx50CV7AZO-
> rBXKETGeFpAXd_O0TIYH
> >
> ZceBVPHbT24andbjyZvaQBHcPsoC62d0MAYDjoe9YrPnuAg2i15Z3SCJkmVn4uH
> GorLgZr
> >
> iWMT1D9ae_3pUEAwdLQCdG5DeTh_XQuRfy6nkCNqdu33T21ke5AHrkv4ynQkr
> YfWuuUGTW
> > bKXPcvTlLrtTXVRAHns1t0OUFp5gA-pXrw_2a-YKf2C3IkEFjzQ1KM07-
> 

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

2018-10-11 Thread Tim Hollebeek via dev-security-policy
I think "Not applicable" would be superior to "No stipulation", when 
appropriate.

"3.2.2.5. No IP address certificates are issued under this CPS." is even 
clearer.

I haven't looked into the implications of this, but perhaps it would be worth 
considering not allowing "No stipulation" in CPSs for sections that are not
marked "No stipulation" in the Baseline Requirements.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jakob Bohm via dev-security-policy
> Sent: Wednesday, October 10, 2018 6:09 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Jakob Bohm 
> Subject: Re: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS
> 
> On 09/10/2018 23:15, Wayne Thayer wrote:
> > On Tue, Oct 9, 2018 at 12:48 PM Kathleen Wilson via
> > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Oh, so rather than trying to define what "No Stipulation" means and
> >> when it can be used, we could take a different approach -- list the
> >> sections that cannot contain "No Stipulation" in the CPS.
> >>
> > This approach implies that we are adopting the RFC 3647 definition of
> > "no stipulation" meaning "we can do whatever we want", not the meaning
> > of "we don't do this" that I believe is intended in the examples your
> > provided. If we take this approach, we should specify those section
> > that **must be
> > present** and cannot contain "no stipulation" (or similar permissive
> > language). Omitting a section defined in RFC 3647 is equivalent to "no
> > stipulation".
> >
> 
> In formulating Mozilla Policy one should also consider the case that a section
> is rendered inapplicable by the contents of another section.
> 
> For example if another CP/CPS section clearly states that the certificates 
> will
> not contain IP addresses as names (alternative or otherwise), then it would
> be OK to not state how IP addresses are validated.  (Such a section might for
> example state that certificates only contain DNS names).
> 
> As second example, if another CP/CPS section enumerates the validation
> methods used, then it would be OK to omit sections about methods not in
> that enumeration.
> 
> As a third example, the parent section of the section listing BR methods
> could state (in various ways) that only the methods explicitly listed will be
> used.  This particular notation could avoid a CP/CPS change to a "This
> method is not used" section when the corresponding section in the BR is
> changed, added or removed.
> 
> >
> >> On 10/9/18 12:31 PM, Brown, Wendy (10421) wrote:
> >>> Tim  -
> >>>
> >>> I think that statement leaves out the next paragraph of RFC3647:
> >>> In a CP, it is possible to leave certain components, subcomponents,
> >> and/or elements unspecified, and to stipulate that the required
> >> information will be indicated in a policy qualifier, or the document
> >> to which a policy qualifier points. Such CPs can be considered
> >> parameterized definitions. The set of provisions should reference or
> >> define the required policy qualifier types and should specify any 
> >> applicable
> default values.
> >>>
> >>> I think normally the policy qualifier points to a CPS, but it might
> >>> be
> >> some other document.
> >>> But in any case if both CP & CPS say "No stipulation" in regards to
> >> something that Mozilla cares about like what validation methods are
> >> supported for TLS certificates, then it is very hard to evaluate that
> >> set of "disclosed business practices" to determine if the CA operates
> >> in accord with the BRs or Mozilla's policy.
> >>> I think there may be some sections of a CP/CPS that are less
> >>> critical,
> >> but in terms of any section that is critical to the evaluation for
> >> inclusion in a particular trust store, I would expect one of the 2
> >> documents to clearly state the operational practices of the CA rather
> >> than just stating "No Stipulation" in both CP & CPS, unless the
> >> Policy Qualifier in issued certificates points to some other document
> >> that contains that information.
> >>>
> >>> Again - just my personal opinion.
> >>>
> 
> 
> 
> Enjoy
> 
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.
> https://clicktime.symantec.com/a/1/sXnCWBuQE3OxwGzDGFCP8tz2qr4y8b
> NKgbC6-
> _XfwpE=?d=Z2HQ1P_v8531y6J8lUlVsUTcmCX72dez2n3uy6rBVqj3AP_W9Le5
> Kck3YIgBpWiS77d8jWkRS0b6l9KDqFwcKEocqyvVnN5uK-qbUnOkjeAK5nOY-
> I07AC1KoUfhN33_MJaNeohcavrTshCIAAtrsPn_ccAchU2O65lWqwDaHUoHRh
> 9gIYPwwxf7tCdkXlf5pf2-RTSRUapCGMR5i-
> D5rFzE5bLaRqyIJQawRpDBOC8lwAgcAIYySICtdAPtmTtxZaS1ekVbuYxfKKAqnD
> QXB4SuFx0Pm6w9JPnU0xYppl0EUNTCMyfc9XtS_ZVRv5C30dxjSrwQjQ4azrub
> pnWxwa2bSJTbuMGd25gNskRQAmSpLbSupgWEe7g2WWrxkA0nnmE8J4ksZu
> JonRs5qSCPxAduJkwssCKkmmZatvuGPimdKnfVibZ07vgopAqoQ7ZmszJyA1jt3
> Wv4weiQ&u=https%3A%2F%2Fwww.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 fo

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

2018-10-09 Thread Tim Hollebeek via dev-security-policy
RFC 3647 disagrees:

"Rather, a particular CP or CPS may state "no stipulation" for a component,
 subcomponent, or element on which the particular CP or CPS imposes no
 requirements or makes no disclosure."

" It is recommended that each and every component and subcomponent be
   included in a CP or CPS, even if there is "no stipulation"; this will
   indicate to the reader that a conscious decision was made to include
   or exclude a provision concerning that topic.  This drafting style
   protects against inadvertent omission of a topic, while facilitating
   comparison of different certificate policies or CPSs, e.g., when
   making policy mapping decisions."

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Brown, Wendy (10421) via dev-security-policy
> Sent: Tuesday, October 9, 2018 2:55 PM
> To: dev-security-policy@lists.mozilla.org
> Subject: RE: What does "No Stipulation" mean, and when is it OK to use it
in
> CP/CPS?
> 
> Kathleen -
> My interpretation of a "No Stipulation" in a CP is that the Policy has "No
rules
> defined for this section"
> In these cases, I expect the CPS to state what is actually done in support
of
> that section and therefore "No Stipulation" is not appropriate in a CPS.
The
> CPS should instead state whether or not they implement anything in
response
> to that section or if they consider that section Not Applicable because
there
> are no stated requirements.
> 
> It can mean slightly different things in different sections so for example
> 1.3.5 Other Participants - I would expect the CPS to list what other
> participants might be involved Where as
> 3.1.5 Uniqueness of Names - I would expect the CPS to state whether or not
> they enforce Uniqueness of names and if they do - how this is enforced In
a
> TLS CP/CPS that adheres to the BRs, I would expect the CPS to clearly
state
> which of the validation methods is supported and how, where the CP may
> leave this up to individual subordinate CAs by having No Stipulation at
the CP
> level.  For these sections I would expect the CPS to either state the
method is
> not supported or it is and how.  "Not applicable" would not be
appropriate.
> 
> Thanks, (just my personal opinion)
> 
> Wendy Brown
> Protiviti Government Services
> 703-299-4705 (office)703-965-2990 (cell)
> 
> wendy.br...@protiviti.com
> 
> 
> -
> 
> Date: Tue, 9 Oct 2018 09:48:26 -0700
> From: Kathleen Wilson 
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: What does "No Stipulation" mean, and when is it OK to use it in
> CP/CPS?
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> All,
> 
> I would like to create some written rules about using "No Stipulation"
> in CP and CPS documents; e.g. what it means, and when it is OK to be used.
> 
> First, I will appreciate your thoughts about what the term "No
Stipulation"
> means. e.g. does it mean one or all of the following?
>   "No rules defined for this section"
>   "This section is not applicable"
>   "This section is not allowed"
>   "This section is not used"
> 
> Can "No Stipulation" mean different things based on the context of the
> section?
> For example
> "1.3.5 Other Participants
> No stipulation."
> Does that mean ?no other participants are allowed??
> 
> Here is what RFC 3647 says about the term:
> ""
> While many topics are identified, it is not necessary for a CP or a
> CPS to include a concrete statement for every such topic.  Rather, a
> particular CP or CPS may state "no stipulation" for a component,
> subcomponent, or element on which the particular CP or CPS imposes no
> requirements or makes no disclosure.  In this sense, the list of
> topics can be considered a checklist of topics for consideration by
> the CP or CPS writer.
> 
> It is recommended that each and every component and subcomponent be
> included in a CP or CPS, even if there is "no stipulation"; this will
> indicate to the reader that a conscious decision was made to include
> or exclude a provision concerning that topic.  This drafting style
> protects against inadvertent omission of a topic, while facilitating
> comparison of different certificate policies or CPSs, e.g., when
> making policy mapping decisions.
> ""
> 
> It seems a little ambiguous to me, so I would like to have a written
statement
> about what "No Stipulation" means within CP and CPS documents, especially
> in regards to SSL certificate issuance.
> 
> Here are two examples that I've seen recently.
> 
> == Example 1 ==
> In this situation, the CA has one CP that covers different types of roots,
so
> the CPS for the different roots has the details. There is no further
detailed
> public documentation beyond the CPS.
> 
> In the CA's CP:
> 3.1.2 Need for Names to be Meaningful
> No Stipulation
> 3.1.5 Uniqueness of Names
> No Stipulation
> 3.2.2.1 Identity
> No Stipulation
> 3.2.2.2 DBA/Tradename
> No Stipulation
> 3.2.2.

RE: Concerns with Dun & Bradstreet as a QIIS

2018-10-01 Thread Tim Hollebeek via dev-security-policy
Getting the whitelist figured out and workable will take a while.  Disclosure 
could happen much faster.

 

And I’m curious why you think it would be unauditable.  It seems 

pretty straightforward to verify such disclosures.

 

It think both ideas are worth considering.  There’s no reason we have to do 
only one or the other.

 

-Tim

 

From: Ryan Sleevi  
Sent: Friday, September 28, 2018 6:35 PM
To: Tim Hollebeek 
Cc: Dimitris Zacharopoulos ; Ian Carroll ; 
mozilla-dev-security-policy ; 
r...@sleevi.com
Subject: Re: Concerns with Dun & Bradstreet as a QIIS

 

Yes, we can punt the problem down a few years, by allowing CAs to self-report 
in unauditable ways, and shift the burden of evaluation on to the community to 
try and detect CAs misbehaving.

 

Or we can take sensible steps forward that nip the problem at its root, don’t 
require misunderstanding or misusing unrelated technologies, and instead 
achieve the goals that CAs have been claiming are valuable to achieve years 
sooner.

 

Obviously, simpler is better - and a whitelist of QGIS quickly establishes an 
interoperable and consistent baseline for organizational information, and can 
be readily deployed today, without any unnecessary infrastructure, and with 
immediate utility to existing relying parties.

 

On Fri, Sep 28, 2018 at 7:43 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

Perhaps a simple first step is to mandate disclosure of which information
source was used for validation.  Then if someone uses Google Maps or
similar, People Who Pay Attention To Such Things can start a public
discussion about whether the source is a QIIS, and whether the certificate
is mis-issued.

This would be yet another use case for my certificate metadata transparency
idea.  CAs have lots of information about the validation, issuance,
management, and revocation of certificates that really does not need to be
private.  As I've noted a few times this year, the issue keeps coming up.

If there were more hours in my day, there'd be an RFC for it already.  If
anyone wants to help with it, I'd be more than happy to work with them.

-Tim

> -Original Message-
> From: dev-security-policy   >
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Friday, September 28, 2018 10:04 AM
> To: Dimitris Zacharopoulos mailto:ji...@it.auth.gr> >
> Cc: mozilla-dev-security-policy
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >;
> Ian Carroll mailto:i...@certly.io> >
> Subject: Re: Concerns with Dun & Bradstreet as a QIIS
> 
> On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via
dev-security-policy
>   > wrote:
> 
> >
> > Forgive my ignorance, but could you please explain what was your
> > ultimate goal, as "an attacker", what were you hoping to gain and how
> > could you use this against Relying Parties?
> >
> > I read your email several times but I could not easily find a case
> > where your fake address creates any serious concern for Relying
> > Parties. Even if you used the same street address as CloudFlare, the
> > CA would check against the database and would find two company records
> > that share the same address. That would obviously block the process
> > and additional checks would take place. Now, as a way to delay
> > certificate issuance for CloudFlare, I find it interesting but it
> > certainly doesn't seem to affect Relying Parties.
> >
> 
> I'm not Ian, but I would have thought his email would have been obvious
and
> clear. The confusion here is that two jurisdictions can allow different
entities
> the same name. The EVGs seek to resolve this by making use of a variety of
> ancilliary fields - such as serialNumber and the incorporation information
- to
> presumably attempt to establish to the relying party the identity they're
> speaking to.
> 
> In the "Stripe, Inc" case, the user was able to distinguish 'real' from
'fake' by
> virtue of the incorporation information - Kentucky vs California.
> However, in this case, the attack went further, in as much as through the
CA
> using an unreliable datasource to verify the jurisdictional information.
> If the CA used an unreliable datasource, then the end user would see
> something that, for intents and purposes, appears the same.
> 
> I'm not sure your point about the same address - Ian made it clear it was
a
> different but *similar* address - and I'm not sure why you suggest it
would
> block for the legitimate subscriber. Does that explain it simply enough?
> 
> 
> > And to take this one step further, I believe there are several GISs
> > that also accept whatever address you tell them because:
> >
> >  1. They have no reason to believe that you will lie to them (they know
> > who you are and in some Jurisdictions you might be prosecuted for
> > lying to the government)
> >  2. No foreseeable harm to others could be done if you misrepresent your
> > own address

RE: Concerns with Dun & Bradstreet as a QIIS

2018-09-28 Thread Tim Hollebeek via dev-security-policy
Perhaps a simple first step is to mandate disclosure of which information
source was used for validation.  Then if someone uses Google Maps or
similar, People Who Pay Attention To Such Things can start a public
discussion about whether the source is a QIIS, and whether the certificate
is mis-issued.

This would be yet another use case for my certificate metadata transparency
idea.  CAs have lots of information about the validation, issuance,
management, and revocation of certificates that really does not need to be
private.  As I've noted a few times this year, the issue keeps coming up.

If there were more hours in my day, there'd be an RFC for it already.  If
anyone wants to help with it, I'd be more than happy to work with them.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Friday, September 28, 2018 10:04 AM
> To: Dimitris Zacharopoulos 
> Cc: mozilla-dev-security-policy
;
> Ian Carroll 
> Subject: Re: Concerns with Dun & Bradstreet as a QIIS
> 
> On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via
dev-security-policy
>  wrote:
> 
> >
> > Forgive my ignorance, but could you please explain what was your
> > ultimate goal, as "an attacker", what were you hoping to gain and how
> > could you use this against Relying Parties?
> >
> > I read your email several times but I could not easily find a case
> > where your fake address creates any serious concern for Relying
> > Parties. Even if you used the same street address as CloudFlare, the
> > CA would check against the database and would find two company records
> > that share the same address. That would obviously block the process
> > and additional checks would take place. Now, as a way to delay
> > certificate issuance for CloudFlare, I find it interesting but it
> > certainly doesn't seem to affect Relying Parties.
> >
> 
> I'm not Ian, but I would have thought his email would have been obvious
and
> clear. The confusion here is that two jurisdictions can allow different
entities
> the same name. The EVGs seek to resolve this by making use of a variety of
> ancilliary fields - such as serialNumber and the incorporation information
- to
> presumably attempt to establish to the relying party the identity they're
> speaking to.
> 
> In the "Stripe, Inc" case, the user was able to distinguish 'real' from
'fake' by
> virtue of the incorporation information - Kentucky vs California.
> However, in this case, the attack went further, in as much as through the
CA
> using an unreliable datasource to verify the jurisdictional information.
> If the CA used an unreliable datasource, then the end user would see
> something that, for intents and purposes, appears the same.
> 
> I'm not sure your point about the same address - Ian made it clear it was
a
> different but *similar* address - and I'm not sure why you suggest it
would
> block for the legitimate subscriber. Does that explain it simply enough?
> 
> 
> > And to take this one step further, I believe there are several GISs
> > that also accept whatever address you tell them because:
> >
> >  1. They have no reason to believe that you will lie to them (they know
> > who you are and in some Jurisdictions you might be prosecuted for
> > lying to the government)
> >  2. No foreseeable harm to others could be done if you misrepresent your
> > own address.
> >
> 
> Then they are not Reliable nor QIISes. Full stop.
> 
> 
> > In my understanding, this is the process each CA must perform to
> > evaluate every Data Source before granting them the "Reliable" or
> > "Qualified" status. Self-reported information without any supporting
> > evidence is clearly not acceptable. I have not evaluated this database
> > that you mention but if they accept self-reporting for "Street Address"
> > and don't perform any additional verification (like asking you for a
> > utility bill or cross-referencing it with a government database), then
> > the "Street Address" information is unreliable and the CA's evaluation
> > process should catch that.
> >
> > That doesn't mean that the rest of the information is also unreliable.
> > For example, an Information Source might describe in their
> > documentation practices how they verify each piece of information, for
> example:
> >
> 
> I disagree with this assessment, and I think it's precisely why greater
> restriction is needed on the flexibility of CAs to make such
interpretations. I
> understand the point you're trying to make - why throw the baby out with
the
> bathwater - but to its use within the EVGs and the BRs, such structural
issues
> throw into fundamental question the status as a RDS or QIIS.
> 
> As you highlight, this is an assessment that each CA makes, according to
its
> own processes and skills, and based on their own understanding.
> Auditors, which while required to have professional understanding of the
> relevant standards but are by no means omniscient nor experts, then also
> 

RE: Concerns with Dun & Bradstreet as a QIIS

2018-09-27 Thread Tim Hollebeek via dev-security-policy
I'm glad you added the smiley, because in my experience CAs have rarely, if 
ever, have had any discretion in such matters.  Nor do we (DigiCert) 
particularly want to, to be honest.  I prefer clear, open, and transparent 
validation rules that other CAs can't play games with.

Whitelisting and disclosure of validation sources was an active topic of 
discussion at the Redmond F2F, if I'm remembering my meetings correctly.  I'm 
surprised that more small CAs didn't support me in that effort at my previous 
employer, as they generally have not taken as much time or effort to find the 
correct sources, and instead rely upon inferior sources.

If that's the direction people want to move, I'd echo Matt's concern that it 
will be a complex and difficult process.  It's best to recall we spent a year 
or three trying to reach consensus about what localities existed in Taiwan and 
how companies could be identified there, and failed.

I'm always willing to work with people on improving the baseline requirements, 
but there needs to be a recognition up front that this is not going to be an 
easy problem to solve, and people need to be willing to volunteer and roll up 
their sleeves and do their part in we're going to undertake such a time 
consuming effort.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Thursday, September 27, 2018 4:18 PM
> To: Matthew Hardeman 
> Cc: mozilla-dev-security-policy 
> ;
> Ian Carroll 
> Subject: Re: Concerns with Dun & Bradstreet as a QIIS
> 
> Yes, it would be work, but would result in consistent and reliable 
> information,
> and already reflective of the fact that an EV certificate needs to identify 
> the
> jurisdictionOfIncorporation and it's incorporating documents. Or are we saying
> that OV doesn't need to make sure it's actually a valid and legal entity, and 
> can
> just display whatever information the CA feels is appropriate? ;)
> 
> 
> On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > A whitelist of QGIS sounds fairly difficult.  And how long would it
> > take to adopt a new one?
> >
> > In some states you're going to have an authority per county.  It'd be
> > a big list.
> >
> > On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi
> wrote:
> > > > Thanks for raising this, Ian.
> > > >
> > > > The question and concern about QIIS is extremely reasonable. As
> > discussed
> > > > in past CA/Browser Forum activities, some CAs have extended the
> > > definition
> > > > to treat Google Maps as a QIIS (it is not), as well as third-party
> > WHOIS
> > > > services (they’re not; that’s using a DTP).
> > > >
> > > > In the discussions, I proposed a comprehensive set of reforms that
> > would
> > > > wholly remedy this issue. Given that the objective of OV and EV
> > > > certificates is nominally to establish a legal identity, and the
> > > > legal identity is derived from State power of recognition, I
> > > > proposed that
> > only
> > > > QGIS be recognized for such information. This wholly resolves
> > differences
> > > > in interpretation on suitable QIIS.
> > > >
> > > > However, to ensure there do not also emerge conflicting
> > > > understandings
> > of
> > > > appropriate QGIS - and in particular, since the BRs and EVGs
> > > > recognize
> > a
> > > > variety of QGIS’s with variable levels of assurance relative to
> > > > the information included - I further suggested that the
> > > > determination of a
> > > QGIS
> > > > for a jurisdictional boundary should be maintained as a normative
> > > whitelist
> > > > that can be interoperably used and assessed against. If a given
> > > > jurisdiction is not included within that whitelist, or the QGIS is
> > > > not
> > on
> > > > it, it cannot be used. Additions to that whitelist can be
> > > > maintained by
> > > the
> > > > Forum, based on an evaluation of the suitability of that QGIS for
> > > purpose,
> > > > and a consensus for adoption.
> > > >
> > > > This would significantly reduce the risk, while also further
> > > > reducing ambiguities that have arisen from some CAs attempting to
> > > > argue that non-employees of the CA or QGIS, but which act as
> > > > intermediaries on
> > > behalf
> > > > of the CA to the QGIS, are not functionally and formally DTPs and
> > > > this subject to the assessment requirements of DTPs. This
> > > > ambiguity is being exploited in ways that can allow a CA to
> > > > nominally say it checked a
> > QGIS,
> > > > but is relying on the word of a third-party, and with no assurance
> > > > of
> > the
> > > > system security of that third party.
> > > >
> > > > Do you think such a proposal would wholly address your concern?
> > >
> > > I think I'll always agree with removing intermediaries from the
> 

RE: SHA-1 exception history

2018-09-27 Thread Tim Hollebeek via dev-security-policy

> On Thu, 27 Sep 2018 14:52:27 +
> Tim Hollebeek via dev-security-policy
>  wrote:
> 
> > My personal impression is that by the time they are brought up here,
> > far too many issues have easily predicted and pre-determined outcomes.
> 
> It is probably true that many issues have predictable outcomes but I think
> predictability is on the whole desirable. Are there in fact CA
representatives
> who'd rather they had no idea how Mozilla would react when there's an
issue?

Asserting that the only alternative to pre-determined outcomes is  "no idea"
is a straw man.

If there is a lack of predictability because I can't predict the results of
an open and honest deliberation among a diverse community, then yes, I want
that.  I would actually love to see more widespread participation by
community members.  Different perspectives are useful.

> > I know most of the security and key management people for the payment
> > industry very well [1], and they're good people.
> 
> I mean this not sarcastically at all, but almost everybody is "good
people".
> That's just not enough. I would like to think that I'm "good people" and
yet it
> certainly would not be a good idea for the Mozilla CA root trust programme
to
> trust some CA root I have on this PC.

Almost everyone is certainly not "good people" in the sense that I meant.
Security is a difficult subject, and people who understand it well are rare.
It unfortunately also tends to attract the personality type that is keen on
finding faults and inherently suspicious of the motivations of others.  I
have a great deal of respect for many of the people I've met who have both a
profound understanding of technical issues and the ability to make sound
decisions.

If you read the entire long historical list of SHA-1 exchanges, you'll find
a profound lack of respect for the opinions of others in many places.  That
tends to cause people to not participate, in much the same way as it caused
me to slowly back away from the conversation at the time.

> > I attempted to speak up a few times in various fora but it was pretty
> > clear that anything that wasn't security posturing wasn't going to be
> > listened to, and finding a practical solution was not on the agenda.
> > It was pretty clear sitting in the room that certain persons had
> > already made up their minds before they even understood what a payment
> > terminal was, how they are managed, and what the costs and risks were
> > for each potential alternative.
> 
> If we're being frank, my impression is that First Data lied in their
submission to
> us and if it came solely to my discretion that would be enough to have
justified
> telling them "No" on its own the first time.

Honestly, First Data is not my favorite company.  I tend to disagree with
their representatives more often than not.  And I'm not asserting they or
others should have gotten what they wanted, only that the level of discourse
was not where it should have been.  This is perhaps less obvious to those
who only followed the discussions on the list, and did not participate on
the calls and in person.

I actually think the tone on m.d.s-p has improved quite a bit in the last
year or two.  It's one of the reasons I participate here from time to time,
where previously I rarely if ever did.  I would like to see it continue
moving in the right direction.

> As to understanding what a payment terminal is, how about "The cheapest
> possible device that passes the bare minimum of tests to scrape through" ?
Is
> that a good characterisation?

It is not.  Such extreme cynicism is generally a symptom of a lack of
objectivity.

-Tim



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


RE: Concerns with Dun & Bradstreet as a QIIS

2018-09-27 Thread Tim Hollebeek via dev-security-policy

> The question and concern about QIIS is extremely reasonable. As discussed in
> past CA/Browser Forum activities, some CAs have extended the definition to
> treat Google Maps as a QIIS (it is not), as well as third-party WHOIS services
> (they’re not; that’s using a DTP).

It's worth noting that the BRs currently say "WHOIS: Information retrieved 
directly from the Domain Name Registrar or registry operator ..." so I'm not 
sure using a DTP is actually permitted.  Though I don't think we've discussed 
that point since the language was added.

> In the discussions, I proposed a comprehensive set of reforms that would
> wholly remedy this issue. Given that the objective of OV and EV certificates 
> is
> nominally to establish a legal identity, and the legal identity is derived 
> from
> State power of recognition, I proposed that only QGIS be recognized for such
> information. This wholly resolves differences in interpretation on suitable 
> QIIS.

We agree with this.

-Tim


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


Re: SHA-1 exception history

2018-09-27 Thread Tim Hollebeek via dev-security-policy
Speaking for myself ...

My personal impression is that by the time they are brought up here, far too
many issues have easily predicted and pre-determined outcomes.

I know most of the security and key management people for the payment
industry very well [1], and they're good people.  The discussions are
generally one or two orders of magnitude more sophisticated (and far more
polite) than what happens in the web ecosystem.  Yes, there's a lot of
silliness in payments, but that's what happens when you try to run and
manage a low cost/high volume payment system with complex interconnected
audit requirements from multiple SDOs, implemented by hundreds of companies
with their own unique perspectives at global scale.

They did not deserve the treatment they received.  Perhaps things would have
gone better if Symantec wasn't involved, but I was shocked at how the
situation was handled.

I attempted to speak up a few times in various fora but it was pretty clear
that anything that wasn't security posturing wasn't going to be listened to,
and finding a practical solution was not on the agenda.  It was pretty clear
sitting in the room that certain persons had already made up their minds
before they even understood what a payment terminal was, how they are
managed, and what the costs and risks were for each potential alternative.

-Tim

[1] whenever you swipe a payment card, the card number is likely encrypted
with keys from an algorithm that I was first to implement: 

https://x9.org/x9news/asc-x9-releases-standard-ensuring-security-symmetric-k
ey-management-retail-financial-transactions-aes-dukpt-algorithm/

https://x9.org/wp-content/uploads/2018/03/X9.24-3-2017-Python-Source-2018012
9-1.pdf

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Thursday, September 27, 2018 5:34 AM
> To: dev-security-policy@lists.mozilla.org
> Cc: Nick Lamb 
> Subject: Re: Google Trust Services Root Inclusion Request
> 
> On Wed, 26 Sep 2018 23:02:45 +0100
> Nick Lamb via dev-security-policy
>  wrote:
> > Thinking back to, for example, TSYS, my impression was that my post on
> > the Moral Hazard from granting this exception had at least as much
> > impact as you could expect for any participant. Mozilla declined to
> > authorise the (inevitable, to such an extent I pointed out that it
> > would happen months before it did) request for yet another exception
> > when TSYS asked again.
> 
> Correction: The incident I'm thinking of is First Data, not TSYS, a
different SHA-
> 1 exception.
> 
> Nick.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/FEUDWpqLnNV5UXAkVPLzsHo_VYc5BQ
> WHYUSdSzjAW5Q=?d=LmNFimUxfoPxKiRYG3qhoRqwu2zE3CPQipLjtaTDkdRpP
> KDL2JS8yPFFNKYTcWKtHyZ4rfj1O0ZZS5x3vkArKDCzRP3ZCC07l-
> SNhD8B4TkkcnDmXJPFlTmuf9Jbc_AGZOos_RYIwD_0TM7s5q9yJyB2Xw6t5iggY1
> qYMgWdJXSo_R6PJYrWiQCv3l_B3q3HEhjoTqZLi0nRxnuoK_Q5ROt-Zy0xZpG-
> sj5lFU44sFfHxhQZR6NBUP6c04vZz2FSHrPV6tFf4x3Sa_hEAhK45l3xKbycZO3xCai
> M4pZCF2dAtJ2mTfuGBl9_FgLu3Btz2-siKIw39AtkuiKptp6JWNszrsiDBQb66B-
> GVQX7M4F7fgMvyaalslF6KHHg5RFi-uOgM8PlilUBCygn0pZylNrU2thPuy-
> Nn9jC&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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


RE: Concerns with Dun & Bradstreet as a QIIS

2018-09-26 Thread Tim Hollebeek via dev-security-policy
There have been previous discussions about this very issue at CA/Browser
Forum Validation Working Group meetings (see also draft Ballot 225).  I
think it is widely recognized that the rules around QIISs are far too weak
and in need of improvement.

I actually recently asked Kirk to add an item on the agenda for the upcoming
Face to Face meeting in Shanghai where we intend to push for the elimination
of the ability to rely upon unofficial information sources, especially Dun &
Bradstreet, for the reasons you cite.  It isn't a reliable information
source.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ian Carroll via dev-security-policy
> Sent: Wednesday, September 26, 2018 4:53 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Concerns with Dun & Bradstreet as a QIIS
> 
> Hi,
> 
> In April and May of this year, I attempted to change the address listed in
Dun
> & Bradstreet of my (Kentucky-incorporated) company "Stripe, Inc" to an
> address in Toledo, Ohio that did not exist (185 Berry Street Toledo Ohio).
I was
> wondering the extent of validation Dun & Bradstreet would do on the data.
> 
> To my surprise, they accepted my change request a couple days later. This
is
> concerning, of course, because D&B is a QIIS backing most EV certificate
> requests in the United States.
> 
> After this worked, I realized this was probably worth exploring more, so I
took
> my "Cloudflare, Inc" company (also incorporated in Kentucky) and requested
> that Dun & Bradstreet change its address to "102 Townsend St San Francisco
> CA". You might notice that this is the same address as the real
Cloudflare, but
> with the street number incremented by one.
> 
> D&B accepted that change request as well. This meant I controlled a DUNS
> number that would resolve to a very similar address to CF, with my phone
> number on it.
> 
> I ordered two EV certificates from Comodo (order #s 136665865 and
> 141269115) with these fake DUNS numbers. I successfully completed the
> validation and callback process for the Cloudflare order, and Comodo was
> about to issue the certificate, but both of my orders were silently
deleted
> before they were about to be issued.
> 
> Comodo would not give me any information about why they (silently)
rejected
> my orders, but Dun & Bradstreet banned my account shortly after, so it is
safe
> to say they reported me after they realized something went wrong.
> 
> I think this is a strong indictment of D&B as a QIIS. The definition of a
QIIS, in
> my opinion, is incredibly lax, but "which is generally recognized as a
> dependable source of such information" is hard to meet here.
> 
> I am also, frankly, annoyed that Comodo seems to have silently discovered
> that D&B was unreliable and then ignored it without reporting it further.
I
> myself have been meaning to send this for a while, given I did this in
May, but
> various things have made it difficult for me to find the time.
> 
> Let me know if I can provide any further information.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/c3r2Ter8o50ppUH1pIlJlwoc7bmoCICI5nzl
> tycPf2k=?d=5ni4BvuKRPoeQ16JRlwwiqHkXFkBGUNLawHjFKnYSsf_1-
> W_uIoVE7PpGy6jmRBVcHjzciQQk9w61dUl2ViqRl9bL4r7h1J9S9DnsSgtX6UGfDf
> Rw3t__-hkOfmQMNa6AXM-enLMWQTxBynJj7o6Tlz6Akz4f-
> aW0KhOd4ZuAiOOxDs_WV7pO1wwY7wj9jCQ6GrgFJ7Zp3yZiiRnOGTKdbrRkzd9
> r7KzcqXr_4GkkZJ2Z78_8-
> Jmhw1XhrraBB_UID6gaAWdIrWxgcU4BJ4fj_Y5rGvyNW8yslAxFPRAz74O5WScx
> _QY7Z1ADHevtAXEsTB9FzRWQunaRP-OX8BfZHBtyGCEeZbV8b_s-
> eJ79m1giXYdCU-v98Yt1xsAk9pA1A-
> ythvQuBnksHG3tYf2auSXR0dbNaCDK46t6yIVXAQ%3D&u=https%3A%2F%2Flist
> s.mozilla.org%2Flistinfo%2Fdev-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


RE: Telia CA - problem in E validation

2018-08-21 Thread Tim Hollebeek via dev-security-policy
There are lots of useful ways to publish unverified and potentially
inaccurate information.

Putting that information into a certificate signed by a public Certificate
Authority is
not one of them.

By the way, OUs need to be accurate as well, not just "partially verified",
so you might
want to look into that part of your processes as well.

BR 7.1.4.2: "By issuing the Certificate, the CA represents that it followed
the procedure 
set forth in its Certificate Policy and/or Certification Practice Statement
to verify that, as 
of the Certificate's issuance date, all of the Subject Information was
accurate."

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 10:45 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
> 
> I believe it has been useful to our users even though it was only
partially
> verified like OU. Now when it no more exists it certainly won't provide
any help
> to anybody.
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/tLUDvyC5tYQiVfqxZIo-c6Uq1a-
> jYOSGbZgRSHyUu1I=?d=zx9qYFefn2ZoXZK3hmoD2hX8Ch__jFtWDZM2CKgWQJ
> Ch5jZYL0ITP0GCk4W9UJI_8nQ6wryVSVMb4y504R9AbIRgEYDp_Umfk051kQR7s
> GVVgzxufqgL7iW3mtbBnroiKhwVEtkMa0IAxmXRTpWu9-
> pldvu8X2WSILON7AWHr-Twz3K3XJ0Ta9hXzKo2YjG4Qhxied-
> um1T97LsQ8H4mpGKC-
> zWuvaCTASohQCwcYAYMEhBqMfI9QS5AYzG3Ba5k10Kum32iQh9lrzUZP-
> 1JnjpJ8PRepHhaa7uNWbZbK_3JMKc_e6PKjA7dXMIqsa846_H9JlvO8TS4cmrHLv
> U0EkO0yv8s75TfAUqiRJlODRxOdcmNpG7-IByKbQxcsYwj1ZFmGkThjIl0AVQ_Y-
> GBp7X48byWDcHqqEkf10tsuQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%
> 2Flistinfo%2Fdev-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


RE: Telia CA - problem in E validation

2018-08-21 Thread Tim Hollebeek via dev-security-policy
Yeah, but unvalidated "information" is not "informative" in any useful way.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 9:59 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
> 
> The purpose of this E value and SAN-rfc822 value is completely different.
The
> former is typically an information to server users where is its support.
The
> latter for email messaging. Thus it is natural that the verification
requirements
> of those two fields are also different (like they are).
> 
> I completely agree that verification of SAN-rfc822 has to be
challenge-response
> or domain based but the same doesn't apply to this E which is only
informative
> field like OU.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/L6gW5CkSOwyu-
> 5hl92vrKoozZhevZGTi1bqkARk0lDA=?d=tcaVpOxV1GZEsht-O5I-
> U1jUfOFbghk57eRNA4QIgc3Uw4rUol-c03Y4fMcVWJF1ZerQdZi4v4h-np-
> 1dARE42nMHSf8aUFNZjD_8NbzDyxU48VdpbKSdRNuh9TCm1_xS39jm-
> iu5N39wqrGYHD09F1LIinG2AXeJODvae0i3tBZynuZyDpFRwK5fgr87sR8O6J9gzW
> vb6SiokKC-
> 2Vd7BTaTuruLtXnLBM25IHfj77EQICOI2CKxe3iYbKmYS7XsoLfUBjpvdbXQ7AwL9
> sV56X2vvD74hClclwAD85eyRj5DtN6_7eqs95arC4rNn3vVKlBuXwUv5M83ljY_sFi
> EBHNG0-8TOuURHS9h-
> L841SrtQumQ8qWSMjOCKHG2Jnn8Xr2OOLWnoY7ZKVoGhEmT7RD8NgG29ipn
> F320B_Lcw%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> 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


RE: Telia CA - problem in E validation

2018-08-21 Thread Tim Hollebeek via dev-security-policy
Previous discussions on this list, which all CAs are required to follow,
have made
it clear that either challenge-response or domain validation is sufficient
to meet
Mozilla's policy for e-mail addresses.

Yes, the context was SMIME validation, but I am very troubled to hear that
instead of using the same rules for E validation, a CA would argue that it's
appropriate or allowed to do virtually no validation at all.  It's not.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 9:41 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
> 
> The first item in Mozilla policy is impossible for all CAs related to E
verification
> because there aren't any valid independent sources to check support email
> addresses. You potentially could validate only domain part of the email
address
> which doesn't cover the requirement that ALL information must be verified
> from such source. Most persons in this discussion have recommended using
> challenge-response method in E verification but I'm afraid it is also
against
> Mozilla requirement 2.1step1 because no independent source or similar is
> involved.
> 
> The second item in Mozilla policy is not valid because these SSL
certificates are
> not capable in email messaging. It is clear for SMIME certificates and
with them
> we follow it.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/_lQ2yVFZFmZcMjnytNPPhWO033O4qV_A
> d55EzA51Pnk=?d=Y3bT5wPI37DMxsvQ8o4N0HWiVOyK-
> eNjbf7Jxhf7xvbeeJ8yf2cm7BADzRYUkQBvJRPouhxTXVjeAHvJIbLkG1NtZ1dnYnq
> Y9ml3RxSoU8xz4soa15OSeMmOPKzQVmJY7ww9X4cgmfNXg_uQol0UxeXzoYO
> yGMgMGSxVEC9cnLih0UOrXrJ5LjeSUxitIBgvH5FkQI1xfXEjNw9wtpbPvdyEhaqo
> ON0bDkt0yC_Hu_UdML9zgpKAP49LuY60sd9_6Qq96a8c8-
> fyjS0hTrOnMPIXsWafHYDN9NT4eHV5nEf1efk9v28xBU02Kv-
> J_s5IwNByYW_TzPwQUEE4faBuitNYmCr_sJkSY2jMpE3xWHJxAGZWtkcKHHOm
> gv6V4X3GGPDexnyYYzEaV2tSYdUJi7zc-uno0zG9-
> CjM7SqOuA%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> 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


RE: Telia CA - problem in E validation

2018-08-21 Thread Tim Hollebeek via dev-security-policy
The BRs indeed do not have many requirements about the validation of email
addresses, but Mozilla policy is much more proscriptive here.  See, for
example, the first two items of section 2.2.

These make it pretty clear that unverified addresses are prohibited by
Mozilla policy, and validation of email addresses is not just a "best
practice"; it's required.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of pekka.lahtiharju--- via dev-security-policy
> Sent: Tuesday, August 21, 2018 6:18 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Telia CA - problem in E validation
> 
> I agree that this culminates to what does it mean when requirement is
"verified
> by CA". When that is not specified anywhere and specifically not in E
validation
> chapter of BR I have interpreted that also weak E verification methods are
> acceptable. I understand that it would be "nice" to use stronger methods
but
> the point is that is it "illegal" to use weak method when such method is
not
> prohibited.
> 
> In our old process we have accepted personal addresses because in some
cases
> a single person is really the "support point" of a server. In practise
personal
> address has only been accepted if the same person is also the technical or
> administrative contact of the application. If anybody would complain or we
> notice in our visual check that the name or address can't be correct we
revoke
> or don't accept. In practice there hasn't been any complaints ever related
to
> our approved E values (except now in the this discussion). Note that all
used E
> values have originated from authenticated customers' CSR.
> 
> Note! Because we want to follow "best practices" we have already stopped
> using these weak methods based on these discussions.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/M8RQ_FBpnEWessS6VTb2TML0gjx1vzlJ-
> To0H9f1Upk=?d=mm6rf8hUuQt34DHH-
> 53_nlyLzE85Upq8F9coCGaDGTmCGJqbCuAdYHeE6BZrlgL64266orhG4-
> qpaAxW71xS5LPicNsPA_DXJT563uavmGor9blfsKv5oGec1ZEtL6DeN_B2af59ky
> WJgTwRpJgPyaePtW0bS56tNfBkLD37-
> _2hgrxOetTnhO0RZE_zIAMg5JQcDNT7HI1pv-
> VWy3I8yTyEv6uw4jcgBZnvM1M8tEXKyVuA9YACauy_kKPqA96LdRL15tLb65uhB
> KHNxSLMNPu3DyrV7cqoOYtj5T0WnlzQCvr8w5KvOuRlrR3p9Em4zmnyGVioHn6
> 64CTycuByUDrGAL6BB806izNaJ_mduZaFq5fgCRIz1Cyjo-
> 0WVWuWqcwLrJFX0Ro-
> 4igDlcfMXvP_f1rwhPByjdggp4xXTQ%3D%3D&u=https%3A%2F%2Flists.mozilla.
> org%2Flistinfo%2Fdev-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


RE: A vision of an entirely different WebPKI of the future...

2018-08-20 Thread Tim Hollebeek via dev-security-policy

The only thing I'm going to say in this thread is that ICANN, registrars,
and registries had two years to figure out how to handle GDPR and email
addresses in WHOIS, and we all know how that turned out.

Maybe we should let them figure out how to handle their existing
responsibilities before we start giving them new ones.

-Tim


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


RE: localhost.megasyncloopback.mega.nz private key in client

2018-08-09 Thread Tim Hollebeek via dev-security-policy
Also, I'd like to encourage other CAs to comply with Issue 98 pro-actively, 
even if it is not required.  We're already in compliance.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Tim Hollebeek via dev-security-policy
> Sent: Thursday, August 9, 2018 10:26 AM
> To: r...@sleevi.com
> Cc: Alex Cohn ; mozilla-dev-security-
> pol...@lists.mozilla.org; ha...@hboeck.de; ssl_ab...@comodoca.com;
> summern1...@gmail.com
> Subject: RE: localhost.megasyncloopback.mega.nz private key in client
> 
> Yup, it was Mozilla policy that I was thinking of.  Thanks.
> 
> 
> 
> I’m sad it didn’t make it into official Mozilla policy, as I thought it was a 
> pretty
> reasonable and non-controversial requirement.  I’d support putting it in the
> BRs.
> 
> 
> 
> -Tim
> 
> 
> 
> From: Ryan Sleevi 
> Sent: Thursday, August 9, 2018 7:15 AM
> To: Tim Hollebeek 
> Cc: Alex Cohn ; ha...@hboeck.de; mozilla-dev-
> security-pol...@lists.mozilla.org; ssl_ab...@comodoca.com;
> summern1...@gmail.com
> Subject: Re: localhost.megasyncloopback.mega.nz private key in client
> 
> 
> 
> Unfortunately, that's not correct. The CA/Browser Forum has passed no such
> resolution, as can be seen at https://cabforum.org/ballots/ .
> 
> 
> 
> I believe you're confusing this with the discussion from
> https://github.com/mozilla/pkipolicy/issues/98, which highlighted that the
> BRs 4.9.3 requires clear instructions for reporting key compromise. That
> language has existed since the BRs 1.3.0 (the conversion to 3647 format).
> 
> 
> 
> Alternatively, you may be confusing this discussion with
> https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communi
> cation , which required CAs to provide a tested email address for a Problem
> Reporting Mechanism. However, as captured in Issue 98, this did not result in
> a normative change to the CP/CPS.
> 
> 
> 
> On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy
> mailto:dev-security-
> pol...@lists.mozilla.org> > wrote:
> 
> IIRC we recently passed a CABF ballot that the CPS must contain instructions
> for submitting problem reports in a specific section of its CPS, in an 
> attempt to
> solve problems like this.  This winter or early spring, if my memory is 
> correct.
> 
> -Tim
> 
> 
> > -Original Message-
> > From: dev-security-policy
> >  > <mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of
> > Alex Cohn via dev-security-policy
> > Sent: Wednesday, August 8, 2018 4:01 PM
> > To: ha...@hboeck.de <mailto:ha...@hboeck.de>
> > Cc: mozilla-dev-security-pol...@lists.mozilla.org
> > <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ;
> > ssl_ab...@comodoca.com <mailto:ssl_ab...@comodoca.com> ;
> > summern1...@gmail.com <mailto:summern1...@gmail.com>
> > Subject: Re: localhost.megasyncloopback.mega.nz
> > <http://localhost.megasyncloopback.mega.nz>  private key in client
> >
> > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck  <mailto:ha...@hboeck.de> > wrote:
> >
> > >
> > > As of today this is still unrevoked:
> > > https://crt.sh/?id=630835231 <https://crt.sh/?id=630835231&opt=ocsp>
> > > &opt=ocsp
> > >
> > > Given Comodo's abuse contact was CCed in this mail I assume they
> > > knew about this since Sunday. Thus we're way past the 24 hour in
> > > which they should revoke it.
> > >
> > > --
> > > Hanno Böck
> > > https://hboeck.de/
> >
> >
> > As Hanno has no doubt learned, the ssl_ab...@comodoca.com
> > <mailto:ssl_ab...@comodoca.com>  address bounces.
> > I got that address off of Comodo CA's website at
> > https://www.comodoca.com/en-us/support/report-abuse/.
> >
> > I later found the address "sslab...@comodo.com
> > <mailto:sslab...@comodo.com> " in Comodo's latest CPS, and forwarded
> > my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I received
> > an automated confirmation immediately afterward, so I assume Comodo
> has now known about this issue for ~70 hours now.
> >
> > crt.sh lists sslab...@comodoca.com <mailto:sslab...@comodoca.com>
> as
> > the "problem reporting" address for the cert in question. I have not tried 
> > this
> address.
> >
> > Comodo publishes at least three different problem reporting email
> > addresses, and at least one of them is nonfunctional. I think similar
> > issues have come up before - there's often not a cle

RE: localhost.megasyncloopback.mega.nz private key in client

2018-08-09 Thread Tim Hollebeek via dev-security-policy
Yup, it was Mozilla policy that I was thinking of.  Thanks.

 

I’m sad it didn’t make it into official Mozilla policy, as I thought it was a 
pretty reasonable and non-controversial requirement.  I’d support putting it in 
the BRs.

 

-Tim

 

From: Ryan Sleevi  
Sent: Thursday, August 9, 2018 7:15 AM
To: Tim Hollebeek 
Cc: Alex Cohn ; ha...@hboeck.de; 
mozilla-dev-security-pol...@lists.mozilla.org; ssl_ab...@comodoca.com; 
summern1...@gmail.com
Subject: Re: localhost.megasyncloopback.mega.nz private key in client

 

Unfortunately, that's not correct. The CA/Browser Forum has passed no such 
resolution, as can be seen at https://cabforum.org/ballots/ .

 

I believe you're confusing this with the discussion from 
https://github.com/mozilla/pkipolicy/issues/98, which highlighted that the BRs 
4.9.3 requires clear instructions for reporting key compromise. That language 
has existed since the BRs 1.3.0 (the conversion to 3647 format).

 

Alternatively, you may be confusing this discussion with 
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication , 
which required CAs to provide a tested email address for a Problem Reporting 
Mechanism. However, as captured in Issue 98, this did not result in a normative 
change to the CP/CPS.

 

On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

IIRC we recently passed a CABF ballot that the CPS must contain instructions
for submitting problem reports in a specific section of its CPS, in an attempt
to solve problems like this.  This winter or early spring, if my memory is 
correct.

-Tim


> -Original Message-
> From: dev-security-policy  <mailto:dev-security-policy-boun...@lists.mozilla.org> > On
> Behalf Of Alex Cohn via dev-security-policy
> Sent: Wednesday, August 8, 2018 4:01 PM
> To: ha...@hboeck.de <mailto:ha...@hboeck.de> 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org 
> <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; 
> ssl_ab...@comodoca.com <mailto:ssl_ab...@comodoca.com> ;
> summern1...@gmail.com <mailto:summern1...@gmail.com> 
> Subject: Re: localhost.megasyncloopback.mega.nz 
> <http://localhost.megasyncloopback.mega.nz>  private key in client
> 
> On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck  <mailto:ha...@hboeck.de> > wrote:
> 
> >
> > As of today this is still unrevoked:
> > https://crt.sh/?id=630835231 <https://crt.sh/?id=630835231&opt=ocsp> 
> > &opt=ocsp
> >
> > Given Comodo's abuse contact was CCed in this mail I assume they knew
> > about this since Sunday. Thus we're way past the 24 hour in which they
> > should revoke it.
> >
> > --
> > Hanno Böck
> > https://hboeck.de/
> 
> 
> As Hanno has no doubt learned, the ssl_ab...@comodoca.com 
> <mailto:ssl_ab...@comodoca.com>  address
> bounces.
> I got that address off of Comodo CA's website at
> https://www.comodoca.com/en-us/support/report-abuse/.
> 
> I later found the address "sslab...@comodo.com <mailto:sslab...@comodo.com> " 
> in Comodo's latest CPS,
> and forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I
> received an automated confirmation immediately afterward, so I assume
> Comodo has now known about this issue for ~70 hours now.
> 
> crt.sh lists sslab...@comodoca.com <mailto:sslab...@comodoca.com>  as the 
> "problem reporting" address for
> the cert in question. I have not tried this address.
> 
> Comodo publishes at least three different problem reporting email addresses,
> and at least one of them is nonfunctional. I think similar issues have come up
> before - there's often not a clear way to identify how to contact a CA. Should
> we revisit the topic?
> 
> Alex
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org 
> <mailto:dev-security-policy@lists.mozilla.org> 
> https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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


RE: localhost.megasyncloopback.mega.nz private key in client

2018-08-09 Thread Tim Hollebeek via dev-security-policy
IIRC we recently passed a CABF ballot that the CPS must contain instructions
for submitting problem reports in a specific section of its CPS, in an attempt
to solve problems like this.  This winter or early spring, if my memory is 
correct.

-Tim

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Alex Cohn via dev-security-policy
> Sent: Wednesday, August 8, 2018 4:01 PM
> To: ha...@hboeck.de
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; ssl_ab...@comodoca.com;
> summern1...@gmail.com
> Subject: Re: localhost.megasyncloopback.mega.nz private key in client
> 
> On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck  wrote:
> 
> >
> > As of today this is still unrevoked:
> > https://crt.sh/?id=630835231&opt=ocsp
> >
> > Given Comodo's abuse contact was CCed in this mail I assume they knew
> > about this since Sunday. Thus we're way past the 24 hour in which they
> > should revoke it.
> >
> > --
> > Hanno Böck
> > https://hboeck.de/
> 
> 
> As Hanno has no doubt learned, the ssl_ab...@comodoca.com address
> bounces.
> I got that address off of Comodo CA's website at
> https://www.comodoca.com/en-us/support/report-abuse/.
> 
> I later found the address "sslab...@comodo.com" in Comodo's latest CPS,
> and forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I
> received an automated confirmation immediately afterward, so I assume
> Comodo has now known about this issue for ~70 hours now.
> 
> crt.sh lists sslab...@comodoca.com as the "problem reporting" address for
> the cert in question. I have not tried this address.
> 
> Comodo publishes at least three different problem reporting email addresses,
> and at least one of them is nonfunctional. I think similar issues have come up
> before - there's often not a clear way to identify how to contact a CA. Should
> we revisit the topic?
> 
> Alex
> ___
> 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


RE: Possible violation of CAA by nazwa.pl

2018-07-27 Thread Tim Hollebeek via dev-security-policy
I agree.

I've actually thought about adding definitions of categories of misissuance 
to the BRs before.  Some of the requirements like revocation are really hard
to write and understand if you don't first categorize all the misissuance use
cases, many of which are very, very different.  And just when I think I have
a reasonable ontology of them in my head ... someone usually goes and 
invents a new one.

Despite how much people like to talk about it, misissuance isn't a defined 
term anywhere, AFAIK.  It can lead to a lot confusing discussions, even 
among experts at the CA/Browser Forum.

-Tim

> -Original Message-
> From: dev-security-policy  bounces+tim.hollebeek=digicert@lists.mozilla.org> On Behalf Of Jakob
> Bohm via dev-security-policy
> Sent: Friday, July 27, 2018 2:46 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Possible violation of CAA by nazwa.pl
> 
> On 26/07/2018 23:04, Matthew Hardeman wrote:
> > On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >>
> >>> The party actually running the authoritative DNS servers is in
> >>> control
> >> of the domain.
> >>
> >> I'm not sure I agree. They can control the domain, but they are
> >> supposed to be subordinate of the domain owner. If they did something
> >> without the owner consent/approval, it really looks like a domain 
> >> hijacking.
> >
> >
> > But the agreement under which they're supposed to be subordinate to
> > the domain owner is a private matter between the domain owner and the
> > party managing the authoritative DNS.  Even if this were domain
> > hijacking, a certificate issued that relied upon a proper domain
> > validation method is still proper issuance, technically.  Once this
> > comes to light, there may be grounds for the proper owner to get the
> > certificate revoked, but the initial issuance was proper as long as
> > the validation was properly performed.
> >
> >
> >>
> >>
> >>> I'm not suggesting that the CA did anything untoward in issuing this
> >>> certificate.  I am not suggesting that at all.
> >>
> >> My opinion is that if the CA was aware that the owner didn't
> >> ask/consent to that issuance, If it's not a misissuance according to
> >> the BRs, it should be.
> >
> >
> > Others can weigh in, but I'm fairly certain that it is not misissuance
> > according to the BRs.  Furthermore, with respect to issuance via
> > domain validation, there's an intentional focus on demonstrated
> > control rather than ownership, as ownership is a concept which can't
> > really be securely validated in an automated fashion.  As such, I
> > suspect it's unlikely that the industry or browsers would accept such a
> change.
> >
> >
> 
> I see this as a clear case of the profound confusion caused by the community
> sometimes conflating "formal rule violation" with "misissuance".
> 
> It would be much more useful to keep these concepts separate but
> overlapping:
> 
>   - A BR/MozPolicy/CPS/CP violation is when a certificate didn't follow the
> official rules in some way and must therefore be revoked as a matter of
> compliance.
> 
>   - An actual misissuance is when a certificate was issued for a private key 
> held
> by a party other than the party identified in the certificate (in Subject 
> Name,
> SAN etc.), or to a party specifically not authorized to hold such a 
> certificate
> regardless of the identity (typically applies to SubCA, CRL-signing, OCSP-
> signing, timestamping or other certificate types where relying party trust
> doesn't check the actual name in the certificate).
> 
>  From these concepts, revocation requirements could then be reasonably
> classified according to the combinations (in addition to any specifics of a
> situation):
> 
>   - Rule violation plus actual misissuance.  This is bad, the 24 hours or 
> faster
> revocation rule should definitely be invoked.
> 
>   - Rule compliant misissuance.  This will inevitably happen some times, for
> example if an attacker successfully spoofs all the things checked by a CA or
> exploits a loophole in the compliant procedures.  This is the reason why there
> must be an efficient revocation process for these cases.
> 
>   - Rule violation, but otherwise correct issuance.  This covers any kind of
> formal violation where the ground truth of the certified matter can still be
> proven.  Ranging from formatting errors (like having "-" in a field that 
> should
> just be omitted, putting the real name with spaces in the common name as
> originally envisioned in X.509, encoding CA:False
> etc.) over potentially dangerous errors (like having a 24 byte serial number,
> which prevents some clients from checking revocation should it ever become
> necessary) to directly dangerous errors (like having an unverified DNS-syntax
> name in CN, or not including enough randomness in the serial number of an
> SHA-1 certificate).
> 
>   - Situation-changed no-longer valid issuance.  T

RE: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

2018-07-13 Thread Tim Hollebeek via dev-security-policy
Yeah, I agree I don’t think it was intended.  But now that I am aware of the 
issue, I think the crossing workaround per EKU is actually a good thing for 
people to be doing.  Unless someone can point out why it's bad ...

Might want to give people a little more time to plan and adapt to that change 
though since I doubt anyone thought of it and people need planning runway to 
change their procedures if it is going to be interpreted this way.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Bruce via
> dev-security-policy
> Sent: Friday, July 13, 2018 10:17 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> S/MIME?
> 
> Agreed that old cross-certificates will not be impacted, but this does impact
> new cross-certificates. I assume the work around would be to just issue more
> than one cross-certificate with different EKUs, but I don't assume that was
> intended by this policy change.
> 
> Bruce.
> 
> On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote:
> > Doesn't the "created after January 1, 2019" mean that there is no problem
> with old crosses?  It would just be a new policy for new crosses as of next 
> year?
> >
> > -Tim
> >
> > > -Original Message-
> > > From: dev-security-policy [mailto:dev-security-policy-
> > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
> > > bounces+Bruce via
> > > dev-security-policy
> > > Sent: Thursday, July 12, 2018 10:28 AM
> > > To: mozilla-dev-security-pol...@lists.mozilla.org
> > > Subject: Re: Do We Now Require Separate Cross-certificates for SSL
> > > and S/MIME?
> > >
> > > Note the BRs define Cross Certificate as "a certificate that is used
> > > to establish a trust relationship between two Root CAs."
> > >
> > > I think the intent was to technically restrict subordinate CAs or
> > > rather CAs which are online and issue end entity certificates. My
> > > assumption is that we want to 1) not allow a subordinate CA to issue
> > > a certificate which it was no intended to issue and 2) mitigate the
> > > risk if an online subordinate CA has been compromised.
> > >
> > > Typically, if an old root cross-certifies a new root, the purpose is
> > > to give the new root browser/OS ubiquity. The new root may be used
> > > to support end entity certificates of many types (e.g., Server Auth,
> > > S/MIME, Client Auth, Code Signing, Document Signing, Time-stamping
> > > ...). If we restrict the cross- certificate, then this will limit
> > > the use of a new root. Also note that the new root is 1) not an
> > > issuing CA and 2) is offline, so the mitigation of technical restriction 
> > > may
> already be satisfied.
> > >
> > > Thanks, Bruce.
> > >
> > > On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote:
> > > > During a 2.6 policy discussion [1], we agreed to add the following
> > > > language to section 5.3 "Intermediate Certificates":
> > > >
> > > > > Intermediate certificates created after January 1, 2019:
> > > > >
> > > > >
> > > > > * MUST contain an EKU extension; and,
> > > > > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
> > > > > * MUST NOT include both the id-kp-serverAuth and
> > > > > id-kp-emailProtection KeyPurposeIds in the same certificate.
> > > > >
> > > >
> > > > It has been pointed out to me that the very next paragraph of
> > > > section
> > > > 5.3
> > > > states:
> > > >
> > > > These requirements include all cross-certified certificates which
> > > > chain to
> > > > > a certificate that is included in Mozilla’s CA Certificate Program.
> > > > >
> > > >
> > > > The term "cross-certified certificates" could refer to the actual
> > > > cross-certificate, or it could refer to intermediate certificates
> > > > that chain up to the cross certificate. In the case of a root that
> > > > is being cross-certified, the former interpretation effectively
> > > > means that distinct cross-certificates would be required for
> > > > serverAuth and emailProtection, as
> > > > follows:
> > > >
> > > > 1 - Root <-- Cross-certificate (EKU=emailProtection) <--
> > > > Intermediate certificate (EKU=emailProtection) <-- leaf
> > > > certificate (S/MIME)
> > > > 2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate
> > > > certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS)
> > > >
> > > > Should our policy require cross-certificates to be constrained to
> > > > either serverAuth or emailProtection via EKU, or should this
> > > > requirement only apply to [all other] intermediate certificates?
> > > >
> > > > What is the correct interpretation of section 5.3 of the policy as
> > > > currently written?
> > > >
> > > > I would appreciate everyone's input on these questions.
> > > >
> > > > - Wayne
> > > >
> > > > [1]
> > > >
> > >
> https://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX

RE: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

2018-07-13 Thread Tim Hollebeek via dev-security-policy
Doesn't the "created after January 1, 2019" mean that there is no problem with 
old crosses?  It would just be a new policy for new crosses as of next year?

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Bruce via
> dev-security-policy
> Sent: Thursday, July 12, 2018 10:28 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> S/MIME?
> 
> Note the BRs define Cross Certificate as "a certificate that is used to 
> establish a
> trust relationship between two Root CAs."
> 
> I think the intent was to technically restrict subordinate CAs or rather CAs
> which are online and issue end entity certificates. My assumption is that we
> want to 1) not allow a subordinate CA to issue a certificate which it was no
> intended to issue and 2) mitigate the risk if an online subordinate CA has 
> been
> compromised.
> 
> Typically, if an old root cross-certifies a new root, the purpose is to give 
> the
> new root browser/OS ubiquity. The new root may be used to support end
> entity certificates of many types (e.g., Server Auth, S/MIME, Client Auth, 
> Code
> Signing, Document Signing, Time-stamping ...). If we restrict the cross-
> certificate, then this will limit the use of a new root. Also note that the 
> new
> root is 1) not an issuing CA and 2) is offline, so the mitigation of technical
> restriction may already be satisfied.
> 
> Thanks, Bruce.
> 
> On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote:
> > During a 2.6 policy discussion [1], we agreed to add the following
> > language to section 5.3 "Intermediate Certificates":
> >
> > > Intermediate certificates created after January 1, 2019:
> > >
> > >
> > > * MUST contain an EKU extension; and,
> > > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
> > > * MUST NOT include both the id-kp-serverAuth and
> > > id-kp-emailProtection KeyPurposeIds in the same certificate.
> > >
> >
> > It has been pointed out to me that the very next paragraph of section
> > 5.3
> > states:
> >
> > These requirements include all cross-certified certificates which
> > chain to
> > > a certificate that is included in Mozilla’s CA Certificate Program.
> > >
> >
> > The term "cross-certified certificates" could refer to the actual
> > cross-certificate, or it could refer to intermediate certificates that
> > chain up to the cross certificate. In the case of a root that is being
> > cross-certified, the former interpretation effectively means that
> > distinct cross-certificates would be required for serverAuth and
> > emailProtection, as
> > follows:
> >
> > 1 - Root <-- Cross-certificate (EKU=emailProtection) <-- Intermediate
> > certificate (EKU=emailProtection) <-- leaf certificate (S/MIME)
> > 2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate
> > certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS)
> >
> > Should our policy require cross-certificates to be constrained to
> > either serverAuth or emailProtection via EKU, or should this
> > requirement only apply to [all other] intermediate certificates?
> >
> > What is the correct interpretation of section 5.3 of the policy as
> > currently written?
> >
> > I would appreciate everyone's input on these questions.
> >
> > - Wayne
> >
> > [1]
> >
> https://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH
> iAL
> > jfsD2zgM=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy-
> 9DLApGl29o_1WR_vWTXMDk0d9kBFu
> >
> rU6JcvMPF1WEp4WBRfAgKXpN15C1244hstaDLxsVmE8bwd8UMj0MNvk5w_Q
> C8ibEWzPC_L
> > UljJwJbyQ12v-
> eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWAR
> > mueHAHVd9wo-
> Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1
> > Lo77olEchKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS-
> GdV0BnikfsrccHi35Z67abn6
> > -KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE-
> HQoRmqNABl-nFDxHu
> > Oru-
> 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv
> Y6H_
> >
> W_xOw3VB6Mp7gtxMSK0v72SLI%3D&u=https%3A%2F%2Fgroups.google.com
> %2Fd%2Fm
> > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31p
> FYXlE5W5k=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy-
> 9DLApGl29o_1WR_vWTXMDk0d9kBFurU6JcvMPF1WEp4WBRfAgKXpN15C1244
> hstaDLxsVmE8bwd8UMj0MNvk5w_QC8ibEWzPC_LUljJwJbyQ12v-
> eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWARmueHAH
> Vd9wo-
> Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1Lo77olE
> chKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS-GdV0BnikfsrccHi35Z67abn6-
> KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE-HQoRmqNABl-
> nFDxHuOru-
> 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv
> Y6H_W_xOw3VB6Mp7gtxMSK0v72SLI%3D&u=https%3A%2F%2Flists.mozilla.or
> g%2Flistinfo%2Fdev-secur

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-23 Thread Tim Hollebeek via dev-security-policy
Right, this is a fair and excellent summary, and there are things I would 
improve about my responses if I had access to a time machine.  Constraints on 
my time are pretty brutal right now, and that does not always allow me to 
express myself as well as I would like.

 

I perceived, possibly incorrectly, a hesitation that adding at least some 
information about DNSSEC lookups would blow up the size of log files and would 
be difficult at scale.  Our discussion internally reached the conclusion that 
we’re supportive of requiring even more extensive CAA logging, even if it is 
expensive.  At Let’s Encrypt’s scale and our scale, that’s an important 
concern, and we think it should be publicly discussed (Comodo’s perspective 
would be interesting too).  So that’s what I was thinking and ended up saying 
really, really badly.

 

Your discussion here is excellent and worthy of a longer term discussion.  I 
was thinking more along the lines of “are there any appropriate quick fixes we 
might want to consider?”  The answer may be no.  But I do find it dangerous 
that minimal compliance with the current requirement can lead to situations 
like this.  That alone makes me want to improve the requirement.

 

And while I’m on the subject, since it’s related: Jeremy and I do have a new 
policy of trying to err on the side of publicly oversharing internal 
information and deliberations, whenever we can.  We think it’s the right thing 
to do.

 

-Tim

 

I definitely think we've gone off the rails here, so I want to try to right the 
cart here. You jumped in on a thread talking about DNSSEC providing smoking 
guns [1] - which is a grandstanding bad idea. It wasn't yours, but it's one 
that you jumped into the middle of the discussion, and began offering other 
interpretations (such as it being about disk space [2]), when the concern was 
precisely about trying to find a full cryptographic proof that can be stable 
over the lifetime of the certificate - which for Let's Encrypt is 90 days, but 
for some CAs, is up to 825-days [3].

 

As a systemic improvement, I think we're in violent agreement about the goal - 
which is to make sure that when things go wrong, there are reliable ways to 
identify where and why they went wrong - and perhaps simply in disagreement on 
the means and ways to effect that. You posited that the original motivation was 
that this specifically could not occur - but I don't think that was actually 
shared or expressed, precisely because there were going to be inherent limits 
to that information. I provided examples of where and how, under the existing 
BRs, that the steps taken are both consistent with and, arguably, above and 
beyond, what is required elsewhere - which is not to say we should not strive 
for more, but is to put down the notion from (other) contributors that somehow 
there's been less here.

 

I encouraged you to share more of your thinking, precisely because this is what 
allows us to collectively evaluate the fitness for purpose [4] - and the 
potential risks that well-intentioned changes can pose [5]. I don't think it 
makes sense to anchor on the CAA aspect as the basis to improve [6], when the 
real risk is the validation methods themselves. If our intent is to provide 
full data for diagnostic purposes, then how far does that rabbit hole go - do 
HTTP file-based validations need to record their DNS lookup chains? Their IP 
flows? Their BGP peer broadcasts? The question of this extreme rests on what is 
it we're trying to achieve - and the same issue here (namely, CAA being 
misparsed) could just as equally apply to HTTP streams, to WHOIS dataflows, or 
to BGP peers.

 

That's why I say it's systemic, and why I say that we should figure out what it 
is we're trying to achieve - and misguided framing [1] does not help further 
that.

 

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/7L2_zfgfCwAJ

[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/gUT3t7B1CwAJ

[3] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/O7QTGmInCwAJ

[4] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/juHBkWV4CwAJ

[5] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/O5rwCV96CwAJ

[6] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/lpU2dpl8CwAJ

 

 

On Wed, May 23, 2018 at 11:29 AM, Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

You’re free to misattribute whatever motives you want to me.  They’re not true. 
 In fact, I would like to call on you yet again to cease speculating and 
imputing malicious motives onto well-intentioned posts.



The CAA logging requirements failed in this instance.  How do we make them 
better?  I’ll repeat that this isn’t a criticism of Let’s Encrypt, other than 
they had a bug like many of u

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-23 Thread Tim Hollebeek via dev-security-policy
You’re free to misattribute whatever motives you want to me.  They’re not true. 
 In fact, I would like to call on you yet again to cease speculating and 
imputing malicious motives onto well-intentioned posts.

 

The CAA logging requirements failed in this instance.  How do we make them 
better?  I’ll repeat that this isn’t a criticism of Let’s Encrypt, other than 
they had a bug like many of us have.  Mozilla wants this to be a place where we 
can reflect on incidents and improve requirements.

 

I’m not looking for something that is full cryptographic proof, that’s can’t be 
made to work.  What are the minimum logging requirements so that CAA logs can 
be used to reliably identify affected certificates when CAA bugs happen?  
That’s the discussion going on internally here.  Love to hear other thoughts on 
this issue.

 

Also, we’re trying to be increasingly transparent about what goes on at 
DigiCert.  I believe we’re the only CA that publishes what we will deliver 
*next* sprint.  I would actually like to share much MORE information than we 
currently do, and have authorization to do so, but the current climate is not 
conducive to that.

 

The fact that I tend to get attacked in response to my sharing of internal 
thinking and incomplete ideas is not helpful or productive.  It will 
unfortunately just cause us to have to stop being as transparent.

 

-Tim

 

I am opposed to unnecessary grand-standing and hand-wringing, when demonstrably 
worse things are practiced.

 



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


RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-22 Thread Tim Hollebeek via dev-security-policy
What that wall of text completely misses is the point I and others have been 
trying to make.

 

The logs have to have enough information so you don’t end up in the situation 
Let’s Encrypt is currently, and unfortunately, in.  Yes, what they did is 
compliant, and that’s exactly what most concerns me.  It’s not about Let’s 
Encrypt, which just appears to have made a mistake, it happens.  It’s about 
whether the rules need to be improved to reduce the likelihood of another CA 
ending up in the same situation.

 

As a separate issue, we’re looking into making sure we never end up in that 
situation, and as you say, other CAs should be too.  We always reserve the 
right to do things that vastly exceed minimal compliance.

 

That should be something you should support, instead of producing increasingly 
long and condescending walls of text.  I know how DNSSEC works.

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, May 22, 2018 12:43 PM
To: Tim Hollebeek 
Cc: r...@sleevi.com; Nick Lamb ; mozilla-dev-security-policy 
; Jacob Hoffman-Andrews 

Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

 

 

 

On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

What precisely was the antecedent of “this” in your message?  Re-reading it, 
I’m not clear which sentence you were referring to.

 

The only reasons I can think of for not keeping DNSSEC signed RRs are storage 
and/or performance, and we think those concerns should not be the driving force 
in logging requirements (within reason).

 

Are there other good reasons not to keep the DNSSEC signed RRs associated with 
DNSSEC CAA lookups?

 

I believe you are operating on a flawed understanding of the value of DNSSEC 
for forensic purposes, given the statement that "I absolutely would expect 
Let's Encrypt to produce DNSSEC signed RRs that match up to their story. The 
smoking gun for such scenarios exists, and CAs are, or should be, under no 
illusions that it's their job to produce it."

 

To me, this demonstrates a flawed, naive understanding of DNSSEC, and in 
particular, its value in forensic post-issuance claims, and also a flawed 
understanding about how DNS works, in a way that, as proposed, would be rather 
severely damaging to good operation and expected use of DNS. While it's easy to 
take shots on the basis of this, or to claim that the only reason not to store 
is because disk space, it would be better to take a step back before making 
those claims.

 

DNSSEC works as short-lived signatures, in which the proper operation of DNSSEC 
is accounted for through frequent key rotation. DNS works through relying on 
factors such as TTLs to serve as effective safeguards against overloading the 
DNS system, and its hierarchal distribution allows for effective scaling of 
that system.

 

A good primer to DNSSEC can be had at 
https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ , although I'm sure 
many other introductory texts would suffice to highlight the problem.

 

Let us start with a naive claim that the CA should be able to produce the 
entire provenance chain for the DNSSEC-signed leaf record. This would be the 
chain of KSKs, ZSKs, the signed RRSets, as well as the DS records, disabling 
caching for all of these (or, presumably, duplicating it such that the .com KSK 
and ZSK are recorded for millions of certs).

 

However, what does this buy us? Considering that the ZSKs are intentionally 
designed to be frequently rotated (24 - 72 hours), thus permitting weaker key 
sizes (RSA-512), a provenance chain ultimately merely serves to establish, in 
practice, one of a series of 512-bit RSA signatures. Are we to believe that 
these 512-bit signatures, on whose keys have explicitly expired, are somehow a 
smoking gun? Surely not, that'd be laughably ludicrous - and yet that is 
explicitly what you propose in the quoted text.

 

So, again I ask, what is it you're trying to achieve? Are you trying to provide 
an audit trail? If so, what LE did is fully conformant with that, and any CA 
that wishes to disagree should look inward, and see whether their audit trail 
records actual phone calls (versus records of such phone calls), whether their 
filing systems store the actual records (versus scanned copies of those 
records), whether all mail is delivered certified delivery, and how they recall 
the results of that certified delivery.

 

However, let us not pretend that recording the bytes-on-the-wire DNS responses, 
including for DNSSEC, necessarily helps us achieve some goal about repudiation. 
Rather, it helps us identify issues such as what LE highlighted - a need for 
quick and efficient information scanning to discover possible impact - which is 
hugely valuable in its own right, and is an area where I am certain that a 
majority of CAs are woefully lagging in. That LE recorded this at all, beyond 
simply "checked DNS", is more of a credit than a disservice

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-22 Thread Tim Hollebeek via dev-security-policy
What precisely was the antecedent of “this” in your message?  Re-reading it, 
I’m not clear which sentence you were referring to.

 

The only reasons I can think of for not keeping DNSSEC signed RRs are storage 
and/or performance, and we think those concerns should not be the driving force 
in logging requirements (within reason).

 

Are there other good reasons not to keep the DNSSEC signed RRs associated with 
DNSSEC CAA lookups?

 

-Tim



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


RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-22 Thread Tim Hollebeek via dev-security-policy

> Given the TTLs and the key sizes in use on DNSSEC records, why do you
believe
> this?

DigiCert is not sympathetic to disk space as a reason to not keep sufficient
information
in order to detect misissuance due to CAA failures.

In fact, inspired by this issue, we are taking a look internally at what we
log, and
considering the feasibility of logging even more information, including full
DNSSEC 
signed RRs.

-Tim



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


RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-21 Thread Tim Hollebeek via dev-security-policy
Ok.  My biggest concern is not you guys, who are pretty security conscious,
but whether we need to improve the language to make it more clear that the
logging has to be sufficient so that in the event of a bug in the CAA logic,
it is possible to determine which issued certificates are affected and how.

It may be hard to come up with such language, but that was the intent of the
language that was currently there, and if it failed to adequately express
that and needs improvement, we should consider improvements.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
> jacob.hoffmanandrews--- via dev-security-policy
> Sent: Friday, May 18, 2018 2:05 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity
incident
> 
> On Friday, May 18, 2018 at 10:52:25 AM UTC-7, Tim Hollebeek wrote:
> > > Our logging of the CAA records processed does not provide the case
> > > information we need to determine whether other issuances were
> > > affected by this bug.
> >
> > We put a requirement in the BRs specifically so this problem could not
occur:
> >
> > "The CA SHALL log all actions taken, if any, consistent with its
> > processing practice."
> 
> To be clear, we do log every CAA lookup
> (https://clicktime.symantec.com/a/1/3HdZcXUFLJSV752s3qQoA0A6fzGR2WGY
> aa8Vb4eW0is=?d=2Gn0FYgiBMMDYQjPk2an9e5zCmdH8aOEM_a2k8A8ew7ArD
> v0URhjtIEPzgzNAA47eRfCIlwMe3ctM0pXRF0VTUqLXosrX-
> i7uR64LKqy873Aqy3Mii7JCWLQHOPpQWcNp3FWnBu624ZZQANcMTNtqbgJea
> RmalbiW1vABzoOte0IZNRfmkmQES8Nr67RP515OPIifYcBpDbj7_SzCddoRw_Im
> KUgkD70LCvR8NLdXBfk2_bpdPsIPd2MYiWXCpp3qWI_1_XQ9z_eyC1QGzTtcxOF
> DLgSe4rRoyLJQqTaoooPKFGFUX_3SIzP6bjz_SEXUqSWbBz7XRVk1YrZczQFl1NM
> N2BdjOE5nsDTre28cQDZNQ-1dOqbirW3-
> CbCQwcvVjIQBfy3i8vCqAUh4xoVlvk16SNfyCeF3pFZYJ_TtcaaO9Tr8cUp9RHfdwC
> 20jfPFtyRHXscZwhVP2Lfucn9JLErK7kbSczQrqe3GrqCICQf27hRDOnBq5_C&u=ht
> tps%3A%2F%2Fgithub.com%2Fletsencrypt%2Fboulder%2Fblob%2Fmaster%2Fv
> a%2Fcaa.go%23L47). However, we do it at too high a level of abstraction:
It
> doesn't contain the unprocessed return values from DNS. We plan to improve
> that as part of our remediation.
> 
> Our ideal would be to log all DNS traffic associated with each issuance,
> including A, , TXT, and CAA lookups. We initially experimented with
this
> by capturing the full verbose output from our recursive resolver, but
concluded
> that it was not usable for investigations because it was not possible to
associate
> specific query/response pairs with the validation request that caused them
(for
> instance, consider NS referrals, CNAME indirection, and caching). I think
this is
> definitely an area of improvement we could pursue in the DNS ecosystem
that
> would be particularly beneficial for CAs.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/OveGoqfqvlk5eSNt6tWZIf0e1XY5TBocWaY
> xmYcWV4s=?d=2Gn0FYgiBMMDYQjPk2an9e5zCmdH8aOEM_a2k8A8ew7ArDv0
> URhjtIEPzgzNAA47eRfCIlwMe3ctM0pXRF0VTUqLXosrX-
> i7uR64LKqy873Aqy3Mii7JCWLQHOPpQWcNp3FWnBu624ZZQANcMTNtqbgJea
> RmalbiW1vABzoOte0IZNRfmkmQES8Nr67RP515OPIifYcBpDbj7_SzCddoRw_Im
> KUgkD70LCvR8NLdXBfk2_bpdPsIPd2MYiWXCpp3qWI_1_XQ9z_eyC1QGzTtcxOF
> DLgSe4rRoyLJQqTaoooPKFGFUX_3SIzP6bjz_SEXUqSWbBz7XRVk1YrZczQFl1NM
> N2BdjOE5nsDTre28cQDZNQ-1dOqbirW3-
> CbCQwcvVjIQBfy3i8vCqAUh4xoVlvk16SNfyCeF3pFZYJ_TtcaaO9Tr8cUp9RHfdwC
> 20jfPFtyRHXscZwhVP2Lfucn9JLErK7kbSczQrqe3GrqCICQf27hRDOnBq5_C&u=ht
> tps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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


RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

2018-05-18 Thread Tim Hollebeek via dev-security-policy
> Our logging of the CAA records processed does not provide the case
> information we need to determine whether other issuances were affected by
> this bug.

We put a requirement in the BRs specifically so this problem could not occur:

"The CA SHALL log all actions taken, if any, consistent with its processing 
practice."

-Tim


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


RE: question about DNS CAA and S/MIME certificates

2018-05-16 Thread Tim Hollebeek via dev-security-policy


> On Wednesday, May 16, 2018 at 2:16:14 AM UTC-4, Tim Hollebeek wrote:
> > This is the point I most strongly agree with.
> >
> > I do not think it's at odds with the LAMPS charter for 6844-bis,
> > because I do not think it's at odds with 6844.
> 
> Updating 6844 is easy. Just define the tag and specify scope for issue /
> issuewild / issueclient sensibly.

Yup.  I'm optimistic it's something we can get done quickly.

-Tim



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


RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-15 Thread Tim Hollebeek via dev-security-policy
When we debated it last, my predictions were hypothetical.



I wish they had remained hypothetical.



-Tim



From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Wednesday, May 16, 2018 12:33 AM
To: Tim Hollebeek ; mozilla-dev-security-policy 

Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key 
generation to policy)



On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

My only objection is that this will cause key generation to shift to partners 
and
affiliates, who will almost certainly do an even worse job.

>

This is already a Mozilla requirement [1] - we're just moving it into the 
policy document.

>

If you want to ban key generation by anyone but the end entity, ban key
generation by anyone but the end entity.

>

We've already debated this [2] and didn't come to that conclusion.

>

-Tim



[1] 
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files

[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ



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


RE: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Tim Hollebeek via dev-security-policy
This is the point I most strongly agree with.



-Tim



I do not think it's at odds with the LAMPS charter for 6844-bis, because I do 
not think it's at odds with 6844.



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


RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-15 Thread Tim Hollebeek via dev-security-policy
The usual ANSI/ISO rule is that if you protect a strong key with a weak key, 
the 
strong key is now weak.

This is true pretty much regardless of your threat model.  It is absurdly hard 
to
express in terms of auditable requirements, though.

"Your AES-128 key has 112 bits of security because you distributed it under 
RSA-2048" tends to blow people's minds.  Unfortunately.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Dimitris
> Zacharopoulos via dev-security-policy
> Sent: Tuesday, May 15, 2018 1:23 PM
> To: Wayne Thayer 
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> 
> 
> On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:
> >> Did you consider any changes based on Jakob’s comments?  If the
> >> PKCS#12 is distributed via secure channels, how strong does the password
> need to be?
> >>
> >>
> >>
> >>
> > I think this depends on our threat model, which to be fair is not
> > something we've defined. If we're only concerned with protecting the
> > delivery of the
> > PKCS#12 file to the user, then this makes sense. If we're also
> > concerned with protection of the file while in possession of the user,
> > then a strong password makes sense regardless of the delivery mechanism.
> 
> I think once the key material is securely delivered to the user, it is no 
> longer
> under the CA's control and we shouldn't assume that it is. The user might
> change the passphrase of the PKCS#12 file to whatever, or store the private 
> key
> without any encryption.
> 
> 
> Dimitris.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/E-
> jZIz_DR9dHNSNR0HnesMrWlGhwKrsH7HKSGn-
> ocMA=?d=6ILtenW6WksqWaTs1fXNph_dHj9tTUMLmyljUltr1AJzVv0Fmccw1ccb
> 5Nm0sMC99lXGaJMbnwLGFTtPqbgZZO_iGjTsU5ZKkk-
> 1lM0Kna7pLUnb7f6pHvUEwkKCK2vjAxT97AzgmNhqPNrRKxL-
> A918X9yZHSkSajsV9kVDi8uxyH50O_YP9kYXzQQWasQwC1gznxInF34QUQWxQu
> cPWrYt90EnC-dyfRBL_7wsJul-
> RnM8fIbCVSh7k3RCeRjJWPvn1ptBjBM7sJ5C6XM7ZNdfTGA08Djz7BUzrNMXGZC
> uP56D3nR6S7Umx9dm3YDau_KWs5CUjUAqJnSIlaxqx0c188ksRtkrfMRxaginzSga
> OzhCNAdbeikh_p5owiH7vDAsO0EhaZd-
> e40yW9bpteFvmKFsYuUOywhQuFYH3464UYwuRZo6e_EIaicvNuq9hd-
> PK9CmOMs64434iClih-
> _z6qOAD9kYqcJ2ell4I58Z7NUyRIQfqMtobhNSjIg8e_k5byQ4k7g%3D&u=https%
> 3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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


RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-15 Thread Tim Hollebeek via dev-security-policy

> This going to require 19 randomly generated Base64 characters and that does
> not include removing common confused characters which will drive up the
> length a bit more, but if this is what the Mozilla risk assessment came up 
> with,
> then we’ll all have to comply.  I hope there is a sufficiently long time for 
> CAs to
> change their processes and APIs and to roll out updated training and
> documentation to their customers (for this unplanned change).

A reasonable transition period is reasonable.

> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20 character
> password will have just 48 bits of entropy, and characters after that only 
> add 1
> bite of entropy each.  User stink at generating Entropy (right Tim?)

Yes, users struggle to generate a single bit of entropy per character.  This is 
why
users should not generate keys or passwords.

An encoded CSPRNG can hit 5-6 bits of entropy per character, so 20 is a pretty 
good number for password lengths.  Copy/paste solves most of the usability 
issues.

There are some subtleties that require some care, but the general gist is right.

-Tim



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


RE: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Tim Hollebeek via dev-security-policy
I agree with Phillip; if we want email CAA to be a thing, we need to define
and
specify that thing.  And I think it should be a thing.

New RFCs are not that hard and need not even be that long.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Phillip
> Hallam-Baker via dev-security-policy
> Sent: Tuesday, May 15, 2018 9:22 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: question about DNS CAA and S/MIME certificates
> 
> When I wrote CAA, my intention was for it to apply to SSL/TLS certs only.
I did
> not consider S/MIME certs to be relevant precisely because of the
> al...@gmail.com problem.
> 
> I now realize that was entirely wrong and that there is in fact great
utility in
> allowing domain owners to control their domains (or not).
> 
> If gmail want to limit the issue of Certs to one CA, fine. That is a
business choice
> they have made. If you want to have control of your online identity, you
need
> to have your own personal domain. That is why I have hallambaker.com. All
my
> mail is forwarded to gmail.com but I control my identity and can change
mail
> provider any time I want.
> 
> One use case that I see as definitive is to allow paypal to S/MIME sign
their
> emails. That alone could take a bite out of phishing.
> 
> But even with gmail, the only circumstance I could see where a mail
service
> provider like that would want to restrict cert issue to one CA would be if
they
> were to roll out S/MIME with their own CA.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/XjZsJF4yykVlCzqgt57_FIwsOTe0fR6a3C5kS
> Yh_IZ4=?d=lJg-wcLQ8TKi5x2vK8SJOJCjdKNbOFzJppz0UZwOpX_uS1wS1Mw-
> 5j_nOlfxrvZ_g0tSYqMRWJezQvAWyNySPmWiq8oV2gEI6bF-
> MXCodHj66yn6adEuwqxiAwHJd6tamadI6Kf-
> pHadUoBbCN15Wb8AEG3D126zrUxw7umhl5JRMC5lYu4kHiYb5kss5F0cvapf8h_
> U7XuRliUCpAUdVY_VtggCy6Hbk0u6x2IlNY411Cb49wMqOGMavYTwrT8CADJZ_
> OJ3cmVnrJLAclZ2Y96VSVSZpzc4h5UeBneGuFjm8T-ikCgGY3kDZfTHOOex-
> VrdHh0nbhZf-yoOgGiXg0naMQ0MnoHA_-L9tUotMKl1e-yScY5S-
> BG6sVyAe68iMOFtJaUYcyEV14-JlCiHpK8pRgYpdvB1V8O3IASeKCzuOiTPvJLrn-
> gCM2xICBAH-
> QzxWPVhgGZtP9OqMlqRDCJUeiAg9PJt&u=https%3A%2F%2Flists.mozilla.org%
> 2Flistinfo%2Fdev-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


RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-15 Thread Tim Hollebeek via dev-security-policy
My only objection is that this will cause key generation to shift to partners 
and
affiliates, who will almost certainly do an even worse job.

If you want to ban key generation by anyone but the end entity, ban key 
generation by anyone but the end entity.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Tuesday, May 15, 2018 4:10 PM
> To: Dimitris Zacharopoulos 
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> I'm coming to the conclusion that this discussion is about "security 
> theater"[1].
> As long as we allow CAs to generate S/MIME key pairs, there are gaping holes
> in the PKCS#12 requirements, the most obvious being that a CA can just
> transfer the private key to the user in pem format! Are there any objections 
> to
> dropping the PKCS#12 requirements altogether and just forbidding key
> generation for TLS certificates as follows?
> 
> CAs MUST NOT generate the key pairs for end-entity certificates that have an
> EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> anyExtendedKeyUsage.
> 
> - Wayne
> 
> [1] https://en.wikipedia.org/wiki/Security_theater
> 
> On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos 
> wrote:
> 
> >
> >
> > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:
> >
> > Did you consider any changes based on Jakob’s comments?  If the
> > PKCS#12 is distributed via secure channels, how strong does the password
> need to be?
> >
> >
> >
> >
> >
> > I think this depends on our threat model, which to be fair is not
> > something we've defined. If we're only concerned with protecting the
> > delivery of the
> > PKCS#12 file to the user, then this makes sense. If we're also
> > concerned with protection of the file while in possession of the user,
> > then a strong password makes sense regardless of the delivery mechanism.
> >
> >
> > I think once the key material is securely delivered to the user, it is
> > no longer under the CA's control and we shouldn't assume that it is.
> > The user might change the passphrase of the PKCS#12 file to whatever,
> > or store the private key without any encryption.
> >
> >
> > Dimitris.
> >
> ___
> 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


RE: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Tim Hollebeek via dev-security-policy
I think CAA is and should be HTTPS only until there are clear rules for how it 
should work for email, and how to keep web CAA from interfering with email CAA. 
 E-mail is currently the wild west and that needs to be fixed.

 

I’m strongly in favor of email CAA, once we get it ‘right’.  But there’s no 
document out there that specifies what ‘right’ is yet.  And there isn’t much 
value to CAA if only a few CAs do it.

 

That’s why I think we need 8644-bis first.  Or another RFC explaining CAA for 
email.

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, May 15, 2018 12:44 PM
To: Tim Hollebeek 
Cc: r...@sleevi.com; Pedro Fuentes ; 
mozilla-dev-security-policy 
Subject: Re: question about DNS CAA and S/MIME certificates

 

Tim,

 

Could you clarify then. Are you disagreeing that CAA is HTTPS only? As these 
were your words only 3 hours ago - 
https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ

 

On Tue, May 15, 2018 at 12:28 PM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

Blatantly false.  I actually suspect DigiCert might already support CAA for 
email.  I haven’t double-checked.

 

-Tim

 

The only reason that "CAA is HTTPS-only" today is because CAs are not 
interested in doing the 'right' thing.

 

 



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


RE: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Tim Hollebeek via dev-security-policy
The LAMPS re-charter is still open for discussion.  I personally have no 
problem with CAA for email being in scope for 6844-bis.  I’m actually in favor 
of that if it really is currently out of scope (I haven’t checked).  Best to 
ask on the LAMPS charter thread.

 

-Tim

 

From: Wayne Thayer [mailto:wtha...@mozilla.com] 
Sent: Tuesday, May 15, 2018 12:41 PM
To: Tim Hollebeek 
Cc: Ryan Sleevi ; Pedro Fuentes ; 
mozilla-dev-security-policy 
Subject: Re: question about DNS CAA and S/MIME certificates

 

I don't see how this debate is leading us to a solution. Can we just 
acknowledge that, prior to this discussion, the implications of CAA for the 
issuance of email certificates was not well understood by CAs or domain name 
registrants?

 

I share the desire to have a system that fails closed in the presence of any 
CAA record, but that is a challenge as long as ecosystem participants view CAA 
as applicable only to server certificates. The sooner we address this issue, 
the better.

 

Mozilla policy isn't a great place to define CAA syntax. The CA/Browser Forum 
currently has no jurisdiction over email, so at best could define syntax to 
limit CAA scope to server certificates. The scope of the LAMPS recharter for 
6844bis appears too narrow to include this. What is the best path forward?

 

- Wayne

 

On Tue, May 15, 2018 at 9:29 AM Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Blatantly false.  I actually suspect DigiCert might already support CAA for 
email.  I haven’t double-checked.



-Tim



The only reason that "CAA is HTTPS-only" today is because CAs are not 
interested in doing the 'right' thing.



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


RE: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Tim Hollebeek via dev-security-policy
Blatantly false.  I actually suspect DigiCert might already support CAA for 
email.  I haven’t double-checked.

 

-Tim

 

The only reason that "CAA is HTTPS-only" today is because CAs are not 
interested in doing the 'right' thing.

 



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


RE: question about DNS CAA and S/MIME certificates

2018-05-15 Thread Tim Hollebeek via dev-security-policy
CAA is HTTPS only today.  That’s the reality.

 

I don’t have to want to argue in favor of reality.  Reality wins regardless of 
what I do.

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, May 14, 2018 11:55 PM
To: Tim Hollebeek 
Cc: r...@sleevi.com; Pedro Fuentes ; 
mozilla-dev-security-policy 
Subject: Re: question about DNS CAA and S/MIME certificates

 

I'm not sure how that's advancing the discussion forward or adding new 
information. The discussion of CAA and wanting to get feedback predates even 
the IETF finalization, as multiple browsers kept encouraging CAs to experiment 
with and attempt to deploy CAA so that we could make sure the kinks were ironed 
out.

 

Regardless of posturing and grandstanding for past statements, can we at least 
agree that a model that argues "fail open" as a solution is a fundamentally 
insecure one? If there are proponents of a 'fail open' model, especially 
amongst CAs, then does it behove them to specify as quickly as possible a 'fail 
closed' model, so that we don't have to try and divine intent and second guess 
site operators as to whether they meant to restrict HTTPS or everything?

 

Put differently, if you want to argue that CAA is HTTPS only, then you need to 
define a way to ensure it's not HTTPS-only, and ASAP. Otherwise, the solution 
is that when S/MIME BRs come around, we simply cannot and should not second 
guess site operators and try to argue CAA was only 'those' type of certs - and 
instead require anyone with a CAA record to explicitly opt-in to allowing 
(potentially unbounded) S/MIME. I don't see any other realistic or practical 
solution - you can't say "This protects you" and then propose 2 years down the 
road, with S/MIME BRs, that it didn't actually 'protect' the site operator - 
the same way you can't say "Restrict access to these five email addresses" and 
then introduce a dozen more 2 years down the road.

 

On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Normally I’d agree that IETF cannot and should not be a blocker for action at 
Mozilla and/or CABF, but based on our experience with CAA for web certificates, 
I would encourage people to get in their time machines and go back two to three 
years, and listen to Tim standing up and saying “I like CAA for the Web PKI, 
but what have we not thought of?”



-Tim



From: Ryan Sleevi [mailto:r...@sleevi.com <mailto:r...@sleevi.com> ] 
Sent: Monday, May 14, 2018 8:24 PM
To: Tim Hollebeek mailto:tim.holleb...@digicert.com> >
Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; Pedro Fuentes 
mailto:pfuente...@gmail.com> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: question about DNS CAA and S/MIME certificates



I don't actually think there is any IETF component to this. There can be, but 
it's not required to be.



On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>  
<mailto:dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > > wrote:

There’s an IETF component, but minimum necessary standards for email 
certificate issuance is a policy issue, not a technical one.



Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in 
accordance with CAA-bis.”



-Tim




With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.



Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org>  
<mailto:dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > 
https://lists.mozilla.org/listinfo/dev-security-policy




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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


RE: question about DNS CAA and S/MIME certificates

2018-05-14 Thread Tim Hollebeek via dev-security-policy
Normally I’d agree that IETF cannot and should not be a blocker for action at 
Mozilla and/or CABF, but based on our experience with CAA for web certificates, 
I would encourage people to get in their time machines and go back two to three 
years, and listen to Tim standing up and saying “I like CAA for the Web PKI, 
but what have we not thought of?”

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, May 14, 2018 8:24 PM
To: Tim Hollebeek 
Cc: r...@sleevi.com; Pedro Fuentes ; 
mozilla-dev-security-policy 
Subject: Re: question about DNS CAA and S/MIME certificates

 

I don't actually think there is any IETF component to this. There can be, but 
it's not required to be.

 

On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

There’s an IETF component, but minimum necessary standards for email 
certificate issuance is a policy issue, not a technical one.



Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in 
accordance with CAA-bis.”



-Tim




With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.



Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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


RE: question about DNS CAA and S/MIME certificates

2018-05-14 Thread Tim Hollebeek via dev-security-policy
There’s an IETF component, but minimum necessary standards for email 
certificate issuance is a policy issue, not a technical one.

 

Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in 
accordance with CAA-bis.”

 

-Tim

 

With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.

 

Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?



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


RE: question about DNS CAA and S/MIME certificates

2018-05-14 Thread Tim Hollebeek via dev-security-policy

> Today this is a "non-issue" because nothing is obligating CAs to respect 
> CAA,
> and thus they can (and are) doing the thing that helps them issue more
> certificates (and, presumably, make more money) - but that doesn't 
> necessarily
> mean its the right thing.

I can think of at least one CA that values "# of right things done" more
highly than "# of certificates issued".  Actually, I can think of two or 
three.
There are probably more.

> Yes, it means that introducing CAA restrictions for
> S/MIME necessarily means there will need to be a way to distinguish these
> cases, so that an organization could restrict e-mail vs HTTPS - so CAs that 
> wish
> to issue S/MIME should start working on these.

Right.  CAA-bis is a pre-requisite here.

As Neil correctly notes, it would be foolish to try to impose semantics and 
apply
policy from the web CAA records onto email certificate issuance without first
figuring out what the semantics, requirements and policies should be for email
certificate issuance.

-Tim


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


RE: question about DNS CAA and S/MIME certificates

2018-05-14 Thread Tim Hollebeek via dev-security-policy
Yes, but as you correctly point out, this should be taken care of as part of 
the CAA-bis
effort.  The original RFC had enough errors with respect to web certificates; I 
think
it would be irresponsible to apply it to e-mail certificates right now without 
carefully
considering the consequences.

With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.

Slightly higher priority is making sure authenticated encryption modes are used 
with
S/MIME, so people can't play silly games with CBC and harvested ciphertexts.
Everything really needs to start transitioning away from CBC ... but I digress.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Monday, May 14, 2018 11:39 AM
> To: Pedro Fuentes 
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: question about DNS CAA and S/MIME certificates
> 
> It seems perfectly reasonable and desirable to require that CAs, regardless of
> the type of certificate they are issuing, respect CAA.
> 
> If an email provider wishes to restrict some types of certificates (e.g.
> HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
> additional expressions within the CAA syntax.
> 
> However, it would be a long-lasting, and tragic mistake if CAA was presumed to
> 'only' apply to HTTPS - because it would make the same mistake of
> nameConstraints - namely, everything that is not expressly listed as
> permitted/restricted is implicitly permitted - rather than doing what security
> practitioners have long known is the safe and secure base - forbid unless
> expressly permitted (default-deny).
> 
> In terms of order of concerns and constituents, the domain holders needs and
> security goals outweigh those of the notion of users 'owning' an email 
> address.
> 
> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy < dev-
> security-pol...@lists.mozilla.org> wrote:
> 
> > Just to say that looking at this from Europe, I don't see this feasible.
> >
> > Citizens getting their personal eIDAS-compliant certificate go through
> > face-to-face validation and will give virtually any valid e-mail
> > address to appear in their certificate.
> >
> > El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:
> > > I created a new issue suggesting that we add this requirement to
> > > Mozilla
> > > policy: https://github.com/mozilla/pkipolicy/issues/135
> > >
> > > On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy
> > > > < dev-security-policy@lists.mozilla.org> wrote:
> > > >
> > > > > Hello,
> > > > > this question is somewhat outside the current Baseline
> > > > > Requirements,
> > > > but...
> > > > >
> > > > > wouldn't it be normal for the same CAA rules for server
> > > > > certificates
> > to
> > > > > also apply to client certificates when the email address is for
> > > > > a
> > domain
> > > > > that already has a valid CAA policy published in DNS?
> > > > >
> > > > >
> > > > > RFC 6844 doesn't seem to make any distinction between server and
> > S/MIME
> > > > > client certificates, it combines them together by referring to
> > > > certificates
> > > > > "for that domain" as a whole.
> > > > >
> > > > >
> > > > > i tested this last night - i obtained an email certificate from
> > > > > one
> > of
> > > > the
> > > > > CAs participating here (not for this exact address though) and
> > > > > it was happily issued even if CAA records authenticated by
> > > > > DNSSEC do not
> > allow
> > > > > their CA to issue for this domain.
> > > > >
> > > > > Now, this is technically not a mis-issuance because it was a
> > > > > proper email-validated address and their CPS says that CAA is
> > > > > only checked
> > for
> > > > > server-type certificates. It doesn't say anything about CAA
> > validation
> > > > for
> > > > > such client certificates.
> > > > >
> > > > > I got in touch with them and they seemed equally surprised by
> > > > > such intended use case for CAA, so my second question is: is
> > > > > anyone
> > actually
> > > > > checking CAA records for client certificates where an email
> > > > > address
> > is
> > > > > included in the certificate subject info and the EKU includes
> > > > > Secure
> > > > Email?
> > > > >
> > > > >
> > > > > Or is CAA usually checked only for server-type certificates,
> > > > > even if
> > RFC
> > > > > 6844 refers to certificates "for that domain" as a whole?
> > > > >
> > > >
> > > > CAs are generally only checking CAA when they're required to in
> > > > order
>

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-14 Thread Tim Hollebeek via dev-security-policy
For the record, I posted someone else's strength testing algorithm, and pointed
out that it was bad 😊  I personally don't think building strength testing 
algorithms 
is hopeless, and I think good ones are very useful.  I tend to agree with the 
current 
NIST recommendation, which is to primarily only consider length, along with 
things 
like history, dictionary words, and reuse.

But in this case, the public is at risk if the key is compromised, so I don't 
trust a 
password chosen by an end user, no matter what strength function it may or may 
not pass.

Some form of random password of sufficient length, with the randomness coming
from a CSPRNG, encoded into a more user friendly form, is the right answer here.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Hurst via dev-security-policy
> Sent: Friday, May 4, 2018 5:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> 
> > True, but CAs can put technical constraints on that to limit the acceptable
> passwords to a certain strength. (hopefully with a better strength-testing
> algorithm than the example Tim gave earlier)
> 
> Tim is the best of us -- this is hard to do well :)
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/B4EQCI-
> M91W3VFdrYnu8NKa6AWUA0Oca9gCvph6YNAo=?d=1AFyDzj7qs0LPt1qH7YZK
> X7VDlKTG3u4_pF-smh1LdxQUjK6Fx2ySSFy5RdxazxX-
> o23v3NFfmxRdpLUwPqiW6yozAgZPzuSbInOcX3x3V3ANyskgECX5k4aeBDO0z1u
> RHJpH-
> Wb5WOBjb0n16kco9wf4jRlCIO7HgEH4pMHjx4H_POUivn493OPB7U9RX8BArU
> 5U87OFuHYndlG0UK-XvQOKqKu6t_3fatFfevp7IT8Jzm4Ze-
> xwk8jgsytRsxvWQ561mB9wFaxsYkiFLZMBHmsNDACgJKZxHouitR-aXhUbxF-
> fKeFXogKbfDCYiYLqHOe5i8KyS8AzFNsUaZTDGJisXeUJbui5n9H3tF5berZe0DuntP
> V7a9yad9-
> haeyu7NspHh92Niu71JNcWZks3gkKolxwuU9vUfZCdfiIIhMHniPOMkCkMl0ooM
> gbRFl0gnAgmiNcKuIizRC9Z35_snt4pKSXAU12MQLeTdYFZMGmKYEDTvkB2L_So
> 3AZHYfUXATSUeQQlo1zSRKZ5Mapw%3D%3D&u=https%3A%2F%2Flists.mozilla
> .org%2Flistinfo%2Fdev-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


RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-04 Thread Tim Hollebeek via dev-security-policy

> Maybe you want n = 112 / 8 = 14 bytes.

Doh!  Yes.

-Tim



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


RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

2018-05-04 Thread Tim Hollebeek via dev-security-policy
It has generally been understood that a string still "contains at least 112
bits of output from a CSPRNG" if that string has been fed through an
encoding mechanism like Base64 or Base32.

Furthermore, explicit requirements about including mixed case or special
characters leads to some very, very bad and borderline toxic security
requirements.  NIST has recently recanted and admitted they were very, very
wrong in this area and we should not repeat their mistake.

Anything we can do to clarify that an awesome password is:

string password = Base32.Encode(CSPRNG.ReadBytes(n));

where n >= 112, we should do.

BTW United Airlines rates these sorts of passwords as "medium strength".
Password meters that only pay attention to password complexity and not
length are stupid.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
Buschart,
> Rufus via dev-security-policy
> Sent: Thursday, May 3, 2018 6:01 PM
> To: Carl Mehner ; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> Basically I like the new wording:
> 
> > PKCS#12 files [...] SHALL have a password containing at least 112 bits
> > of output from a CSPRNG, [...]
> 
> But I think there is a practical problem here: Directly using the output
of any
> random number generator ("C" or not) to generate a password will lead to
> passwords which contain most probably characters that are either not
> printable or at least not type-able on a 'normal' western style keyboard.
> Therefore I think we need to reword the password strength section a little
bit,
> maybe like the following:
> 
> > PKCS#12 files [...] SHALL have a 14 character long password consisting
> > of characters, digits and special characters based on output from a
> > CSPRNG, [...]
> 
> When I originally proposed my wording, I had the serial numbers in my mind
> (for which directly using the output of a CSPRNG works), but didn't think
on the
> encoding problem.
> 
> 
> With best regards,
> Rufus Buschart
> 
> Siemens AG
> Information Technology
> Human Resources
> PKI / Trustcenter
> GS IT HR 7 4
> Hugo-Junkers-Str. 9
> 90411 Nuernberg, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> www.twitter.com/siemens
> 
> www.siemens.com/ingenuityforlife
> 
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
Hagemann
> Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
> Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik
Neike,
> Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich,
Germany;
> Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
> WEEE-Reg.-No. DE 23691322
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: dev-security-policy
> > [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> > ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
> > Gesendet: Mittwoch, 2. Mai 2018 07:45
> > An: mozilla-dev-security-pol...@lists.mozilla.org
> > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
> > to policy
> >
> > On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote:
> > > Ryan - thanks for raising these issues again. I still have concerns
> > > about getting this specific in the policy, but since we're now
> > > headed down that road...
> > >
> > > On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > A few problems I see with the proposed text:
> > > >
> > > > - What is sufficient? I would go with a definition tied to the
> > > > effective strength of the keys it protects; in other words, you
> > > > should protect a 2048bit RSA key with something that offers
> > > > similar properties or that 2048bit key does not live up to its
> > > > 2048 bit properties. This is basically the same CSPRNG
> > > > conversation but it's worth looking at
> > > >
> https://clicktime.symantec.com/a/1/MiD2ZQaRtfOOhnoE5EIpI34AP9rvA3o
> > > >
> INRRu6XdViYU=?d=5Cqt01e3JJ5HJjzKGE6nRW54FeE3IwbVJCyLgL32Lilma6QZm
> k
> > > > H2jvdL5ebp7STf-GpEiDhzmVlSKWJlJz8rGU-
> hyb22kClbCdDKNFH0hcAHEjtrhmva
> > > > pCtr5kNgTYlIotEeIpk2tXzkeWzMD-
> zxkh7R7mriLhGO5p2EWRejSrwIHrBj4b1wF0
> > > > b_wYIQDNW12oF8hKmnVApkn0sJxGRbcSk1-Pw-
> 0cO9oCmj7YktgoxEy_ChyJCL0rNR
> > > > VIAGL4FEFLugnwgUwhflFoN1ujWwINVoDV10imsz_uQ-
> rITP6m0ZtOOaUWWDRhh6rd
> > > > G73BizNHiOU8uKepckQXTmYUBYipG4q6HdZ_-
> bmLcZ4HtlteJxoytWRbIKzqf9X7ld
> > > >
> Pxgq1WlnDDzMiQmsQ0cVAf8MZCcYw8WTa6ax_O7cku54_qoiUKm4qq2Mgj2iz
> UKJ78
> > > > paomt7WfLIvU5KNWQeJ9KK-
> SWt8y9aLxh6QXvaobBri_WOyMUZmrh_tMbpRawssbZY
> > > >
> hA9x1BzLG3a6eWSDgd0MAvNrzh2qCrnGXlSkM6wzvQ%3D%3D&u=https%3A%
> 2F%2Fw
> > > > ww.keylength.com%2F
> > >
> > >
> > > The latest proposal replaces "sufficient" with "at least 64 bits of
> > > output f

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-05-02 Thread Tim Hollebeek via dev-security-policy

> I'd recommend making a requirement that it be "protected" by at least as
many
> bits of strength as the key it protects. Not doing so could cause
compliance
> issues: things like PCI [1] and the NIST [2] recommendations require this
type of
> protection.

You don't have compliance problems because my proposal is weaker than PCI
and NIST (ANSI and ISO also have the same requirement).  It focuses on
RSA-2048
keys because those are what are prevalent in the industry.

If your key is larger than 2048 bits, you can and should use more entropy in
your password, and you have to if you need to comply with PCI/ANSI/ISO [1].
But that's ok because the requirement is >= 112, not exactly 112.

> However, like Wayne said, this still leaves room for interpretation, if
> mentioning bits is necessary, can we just bump it up to 256 rather than
112?

256 is overkill.  People do have to type these passwords sometimes.
112 is the NIST-blessed strength of RSA-2048 [2].  That's why I think it's
the
right number.

-Tim

[1] I left out NIST because it isn't actually a standards body, it just
provides guidance.

[2] Yes, comparing symmetric and asymmetric strengths gets all applesy and
orangey
sometimes, but it's in the right ballpark, and it's a useful number since
it's widely used
and you can point to something to justify it.


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


RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-05-01 Thread Tim Hollebeek via dev-security-policy
I get that, but any CA that can securely erase and forget the user’s 
contribution to the password and certainly do the same thing to the entire 
password, so I’m not seeing the value of the extra complexity and interaction.

 

-Tim

 

From: Ryan Hurst [mailto:ryan.hu...@gmail.com] 
Sent: Tuesday, May 1, 2018 3:49 PM
To: Tim Hollebeek 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

 

> I'm not sure I agree with this as a recommendation; if you want both parties
> to provide inputs to the generation of the password, use a well-established
> and vetted key agreement scheme instead of ad hoc mixing.

> Of course, at that point you have a shared transport key, and you should 
> probably
> just use a stronger, more modern authenticated key block than PKCS#12,
> but that's a conversation for another day.

 

I say this because it is desirable that the CA plausibly not be able to decrypt 
the key even if it holds the encrypted key blob.

 

 

 

On Tue, May 1, 2018 at 12:40 PM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:


> - What is sufficient? I would go with a definition tied to the effective 
> strength of
> the keys it protects; in other words, you should protect a 2048bit RSA key 
> with
> something that offers similar properties or that 2048bit key does not live 
> up to
> its 2048 bit properties.

Yup, this is the typical position of standards bodies for crypto stuff.  I 
noticed that
the 32 got fixed to 64, but it really should be 112.

> - The language should recommend that the "password" be a value that is a mix
> of a user-supplied value and the CSPRNG output and that the CA can not store
> the user-supplied value for longer than necessary to create the PKCS#12.

I'm not sure I agree with this as a recommendation; if you want both parties
to provide inputs to the generation of the password, use a well-established
and vetted key agreement scheme instead of ad hoc mixing.

Of course, at that point you have a shared transport key, and you should 
probably
just use a stronger, more modern authenticated key block than PKCS#12,
but that's a conversation for another day.

> - The language requires the use of a password when using PKCS#12s but
> PKCS#12 supports both symmetric and asymmetric key based protection also.
> While these are not broadly supported the text should not probit the use of
> stronger mechanisms than 3DES and a password.

Strongly agree.

-Tim

 



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


RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-30 Thread Tim Hollebeek via dev-security-policy
OOB passwords are generally tough to integrate into automation, and if the 
channel really is “secure” then they might not be buying you anything, 
depending where the “secure” channel starts and ends and how it is 
authenticated.

 

That might not be a GOOD reason to allow it, but it is the one reason that 
comes to mind.  Taking the other side, I’d argue that it’s unlikely that the 
“secure” channel stretches unbroken from the site of key generation to the key 
loading/usage site.  And it’s possible that “secure” is being used incorrectly, 
and the channel is encrypted but not authenticated.  In that case, having a 
strong password does help for at least a portion of the transmission.

 

-Tim

 

From: Wayne Thayer [mailto:wtha...@mozilla.com] 
Sent: Monday, April 30, 2018 2:25 PM
To: Tim Hollebeek 
Cc: Doug Beattie ; Buschart, Rufus 
; mozilla-dev-security-policy 
; Wichmann, Markus Peter 
; Enrico Entschew ; Grotz, 
Florian ; Heusler, Juergen 

Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

 

The current policy seems inconsistent on the trust placed in passwords to 
protect PKCS#12 files. On one hand, it forbids transmission via insecure 
electronic channels regardless of password protection. But it goes on to permit 
transmission of PKCS#12 files on a storage device as long as a "sufficiently 
strong" password is delivered via a different means. If we trust PKCS#12 
encryption with a strong password (it's not clear that we should [1]), then the 
policy could be:

 

PKCS#12 files SHALL have a password containing at least 64 bits of output from 
a CSPRNG, and the password SHALL be transferred using a different channel than 
the PKCS#12 file.

 

This eliminates the need for separate rules pertaining to physical storage 
devices.

 

Is there a good reason to allow transmission of PKCS#12 files with weak/no 
passwords over "secure" channels?

 

[1] http://unmitigatedrisk.com/?p=543

 

On Mon, Apr 30, 2018 at 10:46 AM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

Once again, CSPRNGs are not overkill.  They are widely available in virtually 
every
programming language in existence these days.  I have never understood why
there is so much pushback against something that often appears near the top of 
many top ten lists about basic principles for secure coding.

Also, while I'm responding, and since it got copied into your proposal, 32 bits 
is 
still way too small.

"irrecoverable physical damage" ?  You want to go beyond tamper evident,
and even tamper responsive, and require self-destruction on tamper??  
I personally think we probably want to get out of the area of writing 
requirements about physical distribution.  They're VERY hard to get right.

That is copied from the current policy, and while it's confusing I believe it 
just means 'tamper evident'.

 

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy- 
>  
> bounces+tim.hollebeek=digicert@lists.mozilla.org 
>  ] On Behalf Of Doug
> Beattie via dev-security-policy
> Sent: Monday, April 30, 2018 1:06 PM
> To: Buschart, Rufus   >; mozilla-dev-security-
> policy   >
> Cc: Wichmann, Markus Peter   >; Enrico
> Entschew mailto:enr...@entschew.com> >; Grotz, Florian
> mailto:florian.gr...@siemens.com> >; Heusler, 
> Juergen
> mailto:juergen.heus...@siemens.com> >; Wayne 
> Thayer mailto:wtha...@mozilla.com> >
> Subject: RE: Policy 2.6 Proposal: Add prohibition on CA key generation to 
> policy

> 
> 
> I agree we need to tighten up Wayne's initial proposal a little.
> 
> -
> Initial proposal (Wayne):
> 
> CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. The PKCS#12 file must have a sufficiently secure
> password, and the password must not be transferred together with the file. If 
> a
> PKCS#12 file is distributed via a physical data storage device, then the 
> storage
> must be packaged in a way that the opening of the package causes
> irrecoverable physical damage. (e.g. a security seal)
> 
> -
> Proposal #1 (Rufus):
> 
> CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. If the CA chooses to do so, the PKCS#12 file 
> SHALL
> have a  password containing at least 32 bit of output from a CSPRNG, and the
> password SHALL be transferred using a different channel as the PKCS#12 file.
> 
> 
> Proposal #2 (Doug)
> 
> If the PKCS#12 is distributed thought an insecure electronic channel then the
> PKCS#12 file SHALL have a  password containing at least 32 bit of entropy and
> the PKCS#12 file and the password SHALL be transferred using a different
> channels.
> 
> If the PKCS#12 is distributed through a secure electronic channel, then...  
>  secure ch

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-30 Thread Tim Hollebeek via dev-security-policy
Once again, CSPRNGs are not overkill.  They are widely available in virtually 
every
programming language in existence these days.  I have never understood why
there is so much pushback against something that often appears near the top of 
many top ten lists about basic principles for secure coding.

Also, while I'm responding, and since it got copied into your proposal, 32 bits 
is 
still way too small.

"irrecoverable physical damage" ?  You want to go beyond tamper evident,
and even tamper responsive, and require self-destruction on tamper??  
I personally think we probably want to get out of the area of writing 
requirements about physical distribution.  They're VERY hard to get right.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Doug
> Beattie via dev-security-policy
> Sent: Monday, April 30, 2018 1:06 PM
> To: Buschart, Rufus ; mozilla-dev-security-
> policy 
> Cc: Wichmann, Markus Peter ; Enrico
> Entschew ; Grotz, Florian
> ; Heusler, Juergen
> ; Wayne Thayer 
> Subject: RE: Policy 2.6 Proposal: Add prohibition on CA key generation to 
> policy
> 
> 
> I agree we need to tighten up Wayne's initial proposal a little.
> 
> -
> Initial proposal (Wayne):
> 
> CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. The PKCS#12 file must have a sufficiently secure
> password, and the password must not be transferred together with the file. If 
> a
> PKCS#12 file is distributed via a physical data storage device, then the 
> storage
> must be packaged in a way that the opening of the package causes
> irrecoverable physical damage. (e.g. a security seal)
> 
> -
> Proposal #1 (Rufus):
> 
> CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. If the CA chooses to do so, the PKCS#12 file 
> SHALL
> have a  password containing at least 32 bit of output from a CSPRNG, and the
> password SHALL be transferred using a different channel as the PKCS#12 file.
> 
> 
> Proposal #2 (Doug)
> 
> If the PKCS#12 is distributed thought an insecure electronic channel then the
> PKCS#12 file SHALL have a  password containing at least 32 bit of entropy and
> the PKCS#12 file and the password SHALL be transferred using a different
> channels.
> 
> If the PKCS#12 is distributed through a secure electronic channel, then...  
>  secure channels are used are there are any requirements on the strength of the
> password or the use of multiple distribution channels?  Can you send both the
> P12 and password in a secure S/MIME email or a user can view/download both
> in the same session from a website?  We should be clear.>
> 
> If a PKCS#12 file is distributed via a non-secure physical data storage device
> , then
> a) the storage must be packaged in a way that the opening of the package
> causes irrecoverable physical damage. (e.g. a security seal), or
> b) the PKCS#12 must have a password of at least 32 bits of entropy and the
> password must be sent via separate channel.
> 
> 
> Comments:
> 
> 1) The discussions to date have not addressed the use of secure channels on
> the quality of the password, nor on the use of multiple channels.  What is the
> intent?  We should specify that so it's clear.
> 
> 2) I think the use of CSPRNG is overkill for this application.  Can we leave 
> this at
> a certain entropy level?
> 
> 3) The tamper requirement would only seem applicable if the P12 wasn't
> protected well (via strong P12 password on USB storage or via "good" PIN on a
> suitably secure crypto token).
> 
> 
> 
> > -Original Message-
> >
> > I would like to suggest to rephrase the central sentence a little bit:
> >
> > Original:
> >
> > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > through insecure electronic channels. The PKCS#12 file must have a
> > sufficiently secure password, and the password must not be transferred
> together with the file.
> >
> > Proposal:
> >
> > CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form
> > through insecure electronic channels. If the CA chooses to do so, the
> > PKCS#12 file SHALL have a  password containing at least 32 bit of
> > output from a CSPRNG, and the password SHALL be transferred using a
> > different channel as the
> > PKCS#12 file.
> >
> > My proposal would allow a CA to centrally generate a P12 file, send it
> > to the Subject by unencrypted email and send the P12 pin as a SMS or
> > Threema message. This is an important use case if you want to have
> > email encryption on a mobile device that is not managed by a mobile device
> management system.
> > Additionally I made the wording a little bit more rfc2119-ish and made
> > clear, what defines a 'sufficiently secure password' as the original
> > wording lets a lot of room for 'interpretation'.
> >
> > What do you think?
> >
> > /Rufus
> >
> >
> > Siemens AG
>

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

2018-04-30 Thread Tim Hollebeek via dev-security-policy
What about the cases we discussed where there is DNSSEC, but only for a
subtree?
Or do you consider that "not DNSSEC" ?

-Tim

> -Original Message-
> From: Paul Wouters [mailto:p...@nohats.ca]
> Sent: Monday, April 30, 2018 11:07 AM
> To: Tim Hollebeek 
> Cc: mozilla-dev-security-policy

> Subject: RE: "multiple perspective validations" - AW: Regional BGP hijack
of
> Amazon DNS infrastructure
> 
> On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote:
> 
> >> I don't think this opinion is in conflict with the suggestion that we
> >> required DNSSEC validation on CAA records when (however rarely) it is
> >> deployed. I added this as
> >> https://github.com/mozilla/pkipolicy/issues/133
> >
> > One of the things that could help quite a bit is to only require
> > DNSSEC validation when DNSSEC is deployed CORRECTLY, as opposed to
> > some partial or broken deployment.  It's generally broken or
> > incomplete DNSSEC deployments that cause all the problems.
> >
> > Getting the rules for this right might be complicated, though.
> 
> It's also wrong. You can't soft-fail on that and you don't want to be in
the
> business of trying to figure out what is a sysadmin failure and what is an
actual
> attack.
> 
> The only somehwat valid soft-fail could come from recently expired RRSIGs,
but
> validating DNS resolvers like unbound already build in a margin of a few
hours,
> and I think you should not to anything special during CAA verification
other
> then using a validating resolver.
> 
> Paul


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


RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-30 Thread Tim Hollebeek via dev-security-policy
32 bits is rather ... low.

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Buschart,
> Rufus via dev-security-policy
> Sent: Monday, April 30, 2018 2:25 AM
> To: mozilla-dev-security-policy 
> 
> Cc: Wichmann, Markus Peter ; Enrico
> Entschew ; Grotz, Florian
> ; Heusler, Juergen
> ; Wayne Thayer 
> Subject: AW: Policy 2.6 Proposal: Add prohibition on CA key generation to
> policy
> 
> ---=== Intern ===---
> Hello!
> 
> I would like to suggest to rephrase the central sentence a little bit:
> 
> Original:
> 
> CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. The PKCS#12 file must have a  sufficiently 
> secure
> password, and the password must not be transferred  together with the file.
> 
> Proposal:
> 
> CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. If the CA chooses to do so, the PKCS#12 file 
> SHALL
> have a  password containing at least 32 bit of output from a CSPRNG, and the
> password SHALL be transferred using a different channel as the PKCS#12 file.
> 
> 
> My proposal would allow a CA to centrally generate a P12 file, send it to the
> Subject by unencrypted email and send the P12 pin as a SMS or Threema
> message. This is an important use case if you want to have email encryption on
> a mobile device that is not managed by a mobile device management system.
> Additionally I made the wording a little bit more rfc2119-ish and made clear,
> what defines a 'sufficiently secure password' as the original wording lets a 
> lot
> of room for 'interpretation'.
> 
> What do you think?
> 
> /Rufus
> 
> 
> Siemens AG
> Information Technology
> Human Resources
> PKI / Trustcenter
> GS IT HR 7 4
> Hugo-Junkers-Str. 9
> 90411 Nuernberg, Germany
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com
> www.twitter.com/siemens
> 
> www.siemens.com/ingenuityforlife
> 
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
> Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
> Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike,
> Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany;
> Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
> WEEE-Reg.-No. DE 23691322
> 
> > -Ursprüngliche Nachricht-
> > Von: dev-security-policy
> > [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> > ozilla.org] Im Auftrag von Wayne Thayer via dev-security-policy
> > Gesendet: Freitag, 27. April 2018 19:30
> > An: Enrico Entschew
> > Cc: mozilla-dev-security-policy
> > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
> > to policy
> >
> > On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > > I suggest to make the requirement „* The PKCS#12 file must have a
> > > sufficiently secure password, and the password must be transferred
> > > via a separate channel than the PKCS#12 file.” binding for both
> > > transfer methods and not be limited to physical data storage.
> > > Otherwise I agree with this proposal.
> > >
> > > Enrico
> > >
> > > That seems like a good and reasonable change, resulting in the
> > > following
> > policy:
> >
> > CAs MUST NOT generate the key pairs for end-entity certificates that
> > have EKU extension containing the KeyPurposeIds id-kp- serverAuth or
> anyExtendedKeyUsage.
> >
> > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > through insecure electronic channels. The PKCS#12 file must have a
> > sufficiently secure password, and the password must not be transferred
> > together with the file. If a PKCS#12 file is distributed via a
> > physical data storage device, then the storage must be packaged in a
> > way that the opening of the package causes irrecoverable physical
> > damage. (e.g. a security seal)
> >
> > Unless other comments are made, I'll consider this to be the conclusion of
> discussion on this topic.
> >
> > Wayne
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> >
> https://clicktime.symantec.com/a/1/HUkfAMaSNDzueZ8VpAI5fwA5As67iQ8caf
> D
> >
> WBr1uThY=?d=ckuHENZYbUJhkHaGquLNZOFaRZP9Zc8e3rxXzIneBrhS9PY6Y5iu
> qxaNSQ
> > CO7umlrvB6qtPvWhKg1hOt-
> 2VGAgBHkdp7nRO9u6gGSrCiQ5v77xypwOc0krIjNpHe3P_8
> > K4fNqBkxtFgHPPRsjnUrWo6Nfut4RREp2XdN4JmAN5a0_Cq-
> KD_3YVYUsmlED3KJBAPwUX
> >
> iunRGjvX_UO6wuk621g6OXR1oeHDV_bXTgF86SIyOLmLgkGFvIqEapcu7fJ586Bw
> XR1uCV
> > 8gq0HQREMlTc_HMD1E4L5sm7g1-GWjLMQdOIJJNK88wXlBK2yuCTd_0K-
> 7Qbvt8DWKSQME
> > NFnvkl5pb6pw6nhSUCEndZT2W45FaXBUVA4HO_-WtnzmCGQavYymFv-
> xnwBMawaicOyUGr
> > FGM3wkQ5QEkKG4HuCXwzqFi-
> 2XstRmiDm9CeSmhFrNoq1pFlsgL0sV8eqyVTAToo95agOr
> > viwOY0FWxUtqdwtZpEaa0-
> Npt_i4xVUnObY1uV

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

2018-04-30 Thread Tim Hollebeek via dev-security-policy

> I don't think this opinion is in conflict with the suggestion that we 
> required
> DNSSEC validation on CAA records when (however rarely) it is deployed. I
> added this as https://github.com/mozilla/pkipolicy/issues/133

One of the things that could help quite a bit is to only require DNSSEC 
validation
when DNSSEC is deployed CORRECTLY, as opposed to some partial or broken
deployment.  It's generally broken or incomplete DNSSEC deployments that
cause all the problems.

Getting the rules for this right might be complicated, though.

-Tim


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


RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

2018-04-26 Thread Tim Hollebeek via dev-security-policy

> > which is why in the near future we can hopefully use RDAP over TLS
> > (RFC
> > 7481) instead of WHOIS, and of course since the near past, DNSSEC :)
> 
> I agree moving away from WHOIS to RDAP over TLS is a good low hanging fruit
> mitigator once it is viable.

My opinion is it is viable now, and the time to transition to optionally 
authenticated RDAP over TLS is now.  It solves pretty much all the problems we 
are currently having in a straightforward, standards-based way.  

The only opposition I've seem comes from people who seem to want to promote 
alternative models that destroy the WHOIS ecosystem, leading to proprietary 
distribution and monetization of WHOIS data.

I can see why that is attractive to some people, but I don’t think it's best 
for everyone.

I also agree that DNSSEC is a lost cause, though I understand why Paul doesn't 
want to give up 😊  I've wanted to see it succeed for basically my entire 
career, but it seems to be making about as much progress as fusion energy.

-Tim


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


RE: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

2018-04-12 Thread Tim Hollebeek via dev-security-policy

> Independent of EV, the BRs require that a CA maintain a High Risk
Certificate
> Request policy such that certificate requests are scrubbed against an
internal
> database or other resources of the CAs discretion.

Unless you're Let's Encrypt, in which case you can opt out of this
requirement via a blog post.

-Tim



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


RE: Policy 2.6 Proposal: Require English Language Audit Reports

2018-04-04 Thread Tim Hollebeek via dev-security-policy
Call me crazy, but for this particular requirement, I think simple sentences
might
be better.

"The audit information MUST be publicly available.  An English version MUST
be provided.  The English version MUST be authoritative."

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Hurst via dev-security-policy
> Sent: Wednesday, April 4, 2018 7:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Policy 2.6 Proposal: Require English Language Audit Reports
> 
> 
> > An authoritative English language version of the publicly-available
> > audit information MUST be supplied by the Auditor.
> >
> > it would be helpful for auditors that issue report in languages other
> > than English to confirm that this won't create any issues.
> 
> That would address my concern.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/qGy7WL45gRate5ccNJV7plt7IjXPV-pd-
> LTa9gPkQc8=?d=fgUiNjCpj8UK6ue4NShfzLGHGzkJWwPb3tOchiTvGntTxuK9bVX
> 5aMMPzBijLrabsuGnsFF4O9QSQsBjPBTpEb0gpSmHGiantqc2OcSQ0D4jZ5aLA1u
> eomyRD8-dNmIp4I87-T1G40WpIGyLEnm-
> Z2ye83FoVpIrjeWcM6ujsgxkvPTYEEPgJJ5S8QA9fQctHsjXIyT8HT8j6vDTknG1enh
> GZ_T_dA6JBbp81zJ4L1Ca2eX6aXcvz5BgcHvS6yotf6bd2EfLLWJKAZnR6o1yRxbzw
> lGl0_7xHVJs8xbMEdUuaI4b4pcup6QbPJsW1UQHIPAR6GFsxCauMSz5EJ-
> 5c38HJOLDPZLF5Tj0N6r-
> JIozX3YVUyZqRdSb4iIILNv8LsXVCwyud6ALgaqx4PJwF_leqzOCmmHBoYDZqI9z0
> 932I7QTktLec_1ZHGSkFGA664AXspslouRvtqP4eZfikJgsBoxEO1G2a2tx6n5uwZle
> -vFX&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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


RE: 825 days success and future progress!

2018-04-02 Thread Tim Hollebeek via dev-security-policy
Ryan, I’ve warned you several times, do not put words in my mouth.  I support 
the status quo, for now.  We can talk about future changes in the future.

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, April 2, 2018 2:58 PM
To: Tim Hollebeek 
Cc: Alex Gaynor ; MozPol 

Subject: Re: 825 days success and future progress!

 

 

 

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

18 months is not significantly different from 825 days.   So there's really
no benefit.

 

So it sounds like you're supportive of 13 months, then, so that we arrive at an 
effective and meaningful maximum.

 

People have to stop wanting to constantly change the max validity period.

 

This is an entirely unproductive line of reasoning. The only reason that we're 
at a point of discussing incremental approaches seems to be because CAs 
resisted making meaningful steps all at once, and instead preferred a phase-in, 
like SHA-1. Proposals were put forward to make it a significant and meaningful 
difference, and there appeared to be wide browser support in spirit - and the 
only question being about the timing of the phase in. Thus, it seems reasonable 
to begin discussing how to approach that - and it doesn't seem productive to 
suggest the community should not discuss this.

 

It's difficult enough to communicate these changes to consumers and
customers, and it really drives them nuts.  I can only imagine what a
non-integral number of years will do to various company's planning
and budgeting processes.

 

So this argues in favor of 13 months, rather than 18 months. The communication 
difficulties are not expanded upon here, but it seems that if CAs spent more 
time investing in interoperable automation, these communication issues would 
evaporate, because they'd no longer be an issue.

 

I would propose, instead, a minimum one year moratorium on proposals
to change the max validity period after the previous change to the max
validity period goes into effect.  That would make much more sense.

 

I'm sure to a CA it makes sense, especially if the argument is that change is 
hard for them to do. Yet, at the same time, attempts to propose moratoriums on 
misissuance by CAs have consistently failed. A moratorium on discussions on how 
to reduce risk only seems valuable if would also imposed a moratorium on trust 
for those CAs that have issues. Since I'm sure that's not desirable for CAs, I 
hope we can agree that discussions of how to reduce the risk of such issues is 
highly relevant and necessary to resolve.



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


RE: 825 days success and future progress!

2018-04-02 Thread Tim Hollebeek via dev-security-policy
Yes, if we wanted to go to 13 months quickly, we would have gone directly 
there.  Getting to 13 months quickly is not a goal.  That’s not having it both 
ways, that having an understanding of how the ecosystem actually works.

 

The majority of the CAB forum, and not just CAs, but also many browsers, 
believe this sort of change so quickly after the most recent change, which came 
very quickly after the change before that, would be unnecessarily disruptive 
and unhelpful to the ecosystem.

 

-Tim

 

From: Alex Gaynor [mailto:agay...@mozilla.com] 
Sent: Monday, April 2, 2018 2:51 PM
To: Tim Hollebeek 
Cc: MozPol 
Subject: Re: 825 days success and future progress!

 

Hi Tim,

 

I'd have suggested an even shorter period, say 13 months, except I anticipated 
CAs would object that it was too great a change too suddenly, precisely as they 
did when this subject was last discussed!

 

While I appreciate that changing BRs can be difficult for customer 
communications, the fact that we are doing this in multiple steps instead of in 
one fell swoop is a result of CAs saying such a big leap was too disruptive. 
Frankly, you can't have it both ways.

 

Alex

 

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

18 months is not significantly different from 825 days.   So there's really
no benefit.

People have to stop wanting to constantly change the max validity period.
It's difficult enough to communicate these changes to consumers and
customers, and it really drives them nuts.  I can only imagine what a
non-integral number of years will do to various company's planning
and budgeting processes.

I would propose, instead, a minimum one year moratorium on proposals
to change the max validity period after the previous change to the max
validity period goes into effect.  That would make much more sense.

-Tim


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy- 
>  
> bounces+tim.hollebeek=digicert@lists.mozilla.org 
>  ] On Behalf Of Alex
> Gaynor via dev-security-policy
> Sent: Monday, April 2, 2018 1:07 PM
> To: MozPol   >
> Subject: 825 days success and future progress!
>
> Afternoon all!
>
> A month ago a new BR rule went into effect, putting a maximum validity
period
> of 825 days on newly issued certificates.
>
> Truthfully, I was expecting tons of CAs to screw up, forget to implement
it, or
> have no technical controls, and there to be tons of miss-issuance.
> To me delight, the results have been pretty good:
> https://crt.sh/?zlint=1081 
>  &minNotBefore=2018-03-01 
> the majority of
> violations have been from the US Government (whose PKI isn't remotely BR
> compliant, nor trusted by Mozilla).
>
> In light of this incredible success, I think it's time to begin a
discussion on what
> the next in this chain is. While obviously actually encoding this in the
BRs will
> be a function of the CABF, as mdsp is the premier public discussion forum
for
> the PKI, I wanted to start here.
>
> I propose that our next target should be a max validity period of 18
months
> (~550 days), starting in ~6 months from now.
>
> The value of shorter-lived certificates has been discussed many times, but
to
> rehash: They afford the ecosystem significantly more agility, by allowing
us to
> remove mistakes in shorter periods of time without breaking valid
certificates.
> It also encourages subscribers to adopt more automation, which further
helps
> with agility.
>
> Alex

> ___
> 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


RE: 825 days success and future progress!

2018-04-02 Thread Tim Hollebeek via dev-security-policy
18 months is not significantly different from 825 days.   So there's really
no benefit.

People have to stop wanting to constantly change the max validity period.
It's difficult enough to communicate these changes to consumers and
customers, and it really drives them nuts.  I can only imagine what a 
non-integral number of years will do to various company's planning 
and budgeting processes.

I would propose, instead, a minimum one year moratorium on proposals
to change the max validity period after the previous change to the max
validity period goes into effect.  That would make much more sense.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Alex
> Gaynor via dev-security-policy
> Sent: Monday, April 2, 2018 1:07 PM
> To: MozPol 
> Subject: 825 days success and future progress!
> 
> Afternoon all!
> 
> A month ago a new BR rule went into effect, putting a maximum validity
period
> of 825 days on newly issued certificates.
> 
> Truthfully, I was expecting tons of CAs to screw up, forget to implement
it, or
> have no technical controls, and there to be tons of miss-issuance.
> To me delight, the results have been pretty good:
> https://crt.sh/?zlint=1081&minNotBefore=2018-03-01 the majority of
> violations have been from the US Government (whose PKI isn't remotely BR
> compliant, nor trusted by Mozilla).
> 
> In light of this incredible success, I think it's time to begin a
discussion on what
> the next in this chain is. While obviously actually encoding this in the
BRs will
> be a function of the CABF, as mdsp is the premier public discussion forum
for
> the PKI, I wanted to start here.
> 
> I propose that our next target should be a max validity period of 18
months
> (~550 days), starting in ~6 months from now.
> 
> The value of shorter-lived certificates has been discussed many times, but
to
> rehash: They afford the ecosystem significantly more agility, by allowing
us to
> remove mistakes in shorter periods of time without breaking valid
certificates.
> It also encourages subscribers to adopt more automation, which further
helps
> with agility.
> 
> Alex
> ___
> 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


RE: Policy 2.6 Proposal: Require disclosure of S/MIME validation practices

2018-03-26 Thread Tim Hollebeek via dev-security-policy
I like this one.

It will be very useful as a starting point if we finally get a CABF S/MIME
working
group, which is likely to happen.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Monday, March 26, 2018 2:50 PM
> To: mozilla-dev-security-policy

> Subject: Policy 2.6 Proposal: Require disclosure of S/MIME validation
practices
> 
> Mozilla policy section 2.2(2) requires validation of email addresses for
S/MIME
> certificates, but doesn't require disclosure of these practices as it does
for TLS
> certificates.
> 
> I propose adding the following language from 2.2 (3) (TLS) to 2.2(2)
> (S/MIME):
> 
> The CA's CP/CPS must clearly specify the procedure(s) that the CA employs
to
> perform this verification.
> 
> This is: https://github.com/mozilla/pkipolicy/issues/114
> 
> ---
> 
> This is a proposed update to Mozilla's root store policy for version 2.6.
Please
> keep discussion in this group rather than on GitHub. Silence is consent.
> 
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> ___
> 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


RE: Policy 2.6 Proposal: Update domain validation requirements

2018-03-20 Thread Tim Hollebeek via dev-security-policy
The language you quoted from me is a bit imprecise, my apologies.

 

I was trying to get CAs to disclose previously undisclosed uses of (4).  There 
are

disclosed uses of (4), including from DigiCert, that haven’t made it into the BR

methods yet, because in the past year, we have failed to pass Jeremy’s IP 
validation

ballot (https://cabforum.org/pipermail/validation/2017-February/000477.html).

I was aware of those at the time I wrote what you quoted, but thought they’d be

in the BRs by now … there was a time when it looked like that ballot was close

to being finalized.

 

The point is that there are IP methods that are not in the BRs that currently 
fall

under (4) that we’ve been trying to get into the BRs for a while now.  DigiCert

would like to be able to continue using the IP validation methods we disclosed

last year, unless there is a reason why they are worse than other disclosed or 

undisclosed methods.

 

-Tim

 

From: Wayne Thayer [mailto:wtha...@mozilla.com] 
Sent: Tuesday, March 20, 2018 5:08 PM
To: Tim Hollebeek 
Cc: mozilla-dev-security-policy 
Subject: Re: Policy 2.6 Proposal: Update domain validation requirements

 

Tim,

 

On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:


> * Add a new bullet on IP Address validation that forbids the use of BR
> 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address
> validation processes in the CA’s CP/CPS.

This is a bit premature.  Most CA's IP validation procedures still fall under
any other method, and the draft ballot that we've been trying to pass
for a year or so is not done yet (I was writing it when the Validation
Summit started taking over my life...)  There's a good chance we will
get a ballot passed on this issue this summer, but there's also a good
chance that work on improving the non-IP validation methods will be
prioritized above it.

This seems to contradict your comment in issue 116 [1]:

 

I think the solution to Ryan's issue is to remove 3.2.2.5 (4). The VWG is 
currently discussing changes to 3.2.2.5 (in order to remove 3.2.2.5 (4)), and 
we haven't heard of any CA that is using it, though we should check the smaller 
ones.

It's possible 3.2.2.5 (4) could be removed with an aggressive timeline if it's 
really true no one is using it.

It would be great to hear from CAs on the impact they would feel from Mozilla 
banning 3.2.2.5(4) prior to passage of the VWG ballot you mentioned.

 

- Wayne

 

[1] https://github.com/mozilla/pkipolicy/issues/116



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


RE: TunRootCA2 root inclusion request

2018-03-12 Thread Tim Hollebeek via dev-security-policy
My reaction was primarily based on the following suggestion:

"Generally speaking I would insist on the fact that for country CAs, some
kind 
of fast tracks should be established because the impact of time losing at
country level is highly expensive."

The answer is, and must be, no.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
> taher.mestiri--- via dev-security-policy
> Sent: Monday, March 12, 2018 10:54 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: TunRootCA2 root inclusion request
> 
> Dear Tim,
> 
> Not sure your penguin-related example would make the picture sharper or
> ideas clearer.
> 
> I asked about fast tracks because it's taking long time to get things
processed
> related to the fact that all this is running by a community and I think it
can be
> great to brainstorm ways to handle maybe work overloads even through paid
> assessments for example.
> 
> I don't think it's worth to answer either your comments about special
> treatment, as no one has asked for it apart of speeding the process which
is not
> special treatment but respect for users and community, or about how
special
> we feel we are, etc.
> 
> I am not a member of the government, I consider myself member of an open
> global IT community, including but not limited to mozilla, that shares
same
> values of respect and mutual help. I find your answer a bit aggressive
but,
> anyway, maybe I was wrong about something that made you answer the way
> you did... That was not my intention.
> 
> I hope that you guys can give us a list of major corrections or
verifications to do
> within a certain limited time to give us the opportunity to get our CA
approved
> without restarting the whole process.
> I hope this is not considered as special treatment as maybe I don't know
what
> kind of support you provide in such cases.
> 
> At the end, I would reiterate that I shared personal opinions and I am not
> member of the government as this is a public open discussion and I don't
want
> that my opinion impacts negaively the decision taking.
> 
> Best,
> 
> Taher.
> 
> 
> 
> On Tuesday, 13 March 2018 03:06:40 UTC+1, Tim Hollebeek  wrote:
> > Nobody is blocking any country from advancing.  There are no Mozilla
> > rules that prevent any country from having the best CA on the planet.
> > If a bunch of penguins at McMurdo station run an awesome CA, I'll ask
> > some hard questions about how they meet the OCSP requirements with
> > their limited bandwidth, but if they have good answers, I'm fine with
> > internet security now being penguins all the way down.
> >
> > If you want your certificates to be accepted everywhere on the planet,
> > you need to follow the same rules as everyone else on the planet.  No
> > fast tracks or special rules for anyone, no matter how special they
> > feel they are.
> >
> > The same rules for everyone is the only sane route forward.
> > Governments often believe they deserve special treatment, and they may
> > have the ability to force that to be true within their own country,
> > but that doesn't make it a good idea for Mozilla.
> >
> > -Tim
> >
> > > -Original Message-
> > > From: dev-security-policy [mailto:dev-security-policy-
> > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
> > > taher.mestiri--- via dev-security-policy
> > > Sent: Monday, March 12, 2018 7:31 PM
> > > To: mozilla-dev-security-pol...@lists.mozilla.org
> > > Subject: Re: TunRootCA2 root inclusion request
> > >
> > > Dear All,
> > >
> > > Thank you for your detailed description of your concerns with the
> > > Tunisian
> > CA.
> > >
> > > I have been one of those guys that developped IT communities for
> > > more than
> > 7
> > > years in Tunisia, starting by Tunandroid (Tunisian Android
> > > Community),
> > Google
> > > Developers Groups, organized the best Software Freedom Day in 2012,
> > > supported local Mozilla Community 2013-2014, GDG Country Champion in
> > > Tunisia 2012-2014 and represented the IT community in law projects
> > > to help developing the local ecosystem since 2013 and still.
> > >
> > > The reason why I am telling you this is to assure you that I
> > > perfectly
> > understand
> > > what a community is about: helping each others, making things better
> > > and sharing knowledge. Things have always been inclusive.
> > >
> > > The Tunisian national digital certification agency has been under
> > > pressure
> > for
> > > more then 3 years to have its CA certificates recognized by Mozilla
> > > and
> > they did
> > > all which is possible to do to have the best security standards when
> > > they
> > got
> > > audited and criticized and they have alwyas been very reactive.
> > >
> > > I would highlight that we are speaking here about a national CA
> > > which is completely different from any other type of agencies. We
> > > are speaking
> > about
> > > blocking a whole

RE: TunRootCA2 root inclusion request

2018-03-12 Thread Tim Hollebeek via dev-security-policy
Nobody is blocking any country from advancing.  There are no Mozilla rules 
that prevent any country from having the best CA on the planet.  If a bunch
of penguins at McMurdo station run an awesome CA, I'll ask some hard
questions about how they meet the OCSP requirements with their limited
bandwidth, but if they have good answers, I'm fine with internet security 
now being penguins all the way down.

If you want your certificates to be accepted everywhere on the planet, you
need to follow the same rules as everyone else on the planet.  No fast
tracks
or special rules for anyone, no matter how special they feel they are.

The same rules for everyone is the only sane route forward.  Governments
often believe they deserve special treatment, and they may have the ability
to force that to be true within their own country, but that doesn't make it
a good idea for Mozilla.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
> taher.mestiri--- via dev-security-policy
> Sent: Monday, March 12, 2018 7:31 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: TunRootCA2 root inclusion request
> 
> Dear All,
> 
> Thank you for your detailed description of your concerns with the Tunisian
CA.
> 
> I have been one of those guys that developped IT communities for more than
7
> years in Tunisia, starting by Tunandroid (Tunisian Android Community),
Google
> Developers Groups, organized the best Software Freedom Day in 2012,
> supported local Mozilla Community 2013-2014, GDG Country Champion in
> Tunisia 2012-2014 and represented the IT community in law projects to help
> developing the local ecosystem since 2013 and still.
> 
> The reason why I am telling you this is to assure you that I perfectly
understand
> what a community is about: helping each others, making things better and
> sharing knowledge. Things have always been inclusive.
> 
> The Tunisian national digital certification agency has been under pressure
for
> more then 3 years to have its CA certificates recognized by Mozilla and
they did
> all which is possible to do to have the best security standards when they
got
> audited and criticized and they have alwyas been very reactive.
> 
> I would highlight that we are speaking here about a national CA which is
> completely different from any other type of agencies. We are speaking
about
> blocking a whole country from advancing.
> 
> It's already unacceptable to have such long process for country CA, if we
have
> to fail and restart we have to fail quickly because time is very valuable.
We
> can't afford restarting the process if the Tunisian CA gets rejected but
instead I
> think anything can be corrected and updated this is how I.T. works.
> 
> Generally speaking I would insist on the fact that for country CAs, some
kind of
> fast tracks should be established because the impact of time losing at
country
> level is highly expensive.
> 
> I have no doubt about your support and hope you can help my country move
> forward and I am sure that the team in our national digital certification
agency
> will do its best to assure you about how seriously we are working to make
> users globally trusting our CA protected.
> 
> Best regards,
> 
> Taher Mestiri
> 
> 
> 
> On Monday, 12 March 2018 15:59:55 UTC+1, Ryan Sleevi  wrote:
> > These responses demonstrate why the request is troubling. They attempt
> > to paint it as "other people do it"
> >
> > The risk of removing an included CA must balance the ecosystem
> > disruption to those non-erroneous certs, while the risk to ecosystem
> > inclusion needs to balance both the aggregate harm to the ecosystem
> > (through lowered
> > standards) and the risk to the ecosystem of rejecting the request (of
> > which, until inclusion is accepted, is low)
> >
> > The pattern of issues - particularly for a new CA - is equally
problematic.
> > A CA, especially in light of the public discussions, should not be
> > having these issues in 2018, and yet, here we are.
> >
> > We are in agreement on the objective facts - namely, that there is a
> > prolonged pattern of issues - and the criteria - namely, that CAs
> > should adhere to the policy in requesting inclusion. A strict
> > adherence to those objectives would be to fully deny the request. It
> > sounds like where we disagree, then, is not in the objective facts and
> > criteria, but rather, where the evaluation of that leaves relative to
risk.
> >
> > The position I am advocating is that, even if these individual matters
> > might be seen as less risky, especially, as has been mentioned, this
> > CA is "only" intended for .tn for the most case, the existence of such
> > a pattern (and the means of acknowledging-but-not-resolving-completely
> > these issues) is indicative that there will continue to be serious
> > issues, and that the risk is not simply limited to .tn, but threatens
> > global Internet stability an

RE: Following up on Trustico: reseller practices and accountability

2018-03-12 Thread Tim Hollebeek via dev-security-policy
You might be interested in the following blog post:

https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practice
s/

We are continuing to look into whether there are any additional partners or
resellers that are misbehaving.  This may indeed be an area where stricter
requirements are necessary, though it's a complicated problem.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Eric
Mill
> via dev-security-policy
> Sent: Sunday, March 11, 2018 1:16 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Following up on Trustico: reseller practices and
accountability
> 
> Though I'm not a GlobalSign customer, I'm told that GlobalSign sent the
> following email to its partner ecosystem:
> 
> Dear Partner,
> 
> In reaction to current events related to the private key exposure and mass
> revocation by Trustico/Digicert, GlobalSign is reaching out to its trusted
> Partners and Resellers to survey how they approach customer private key
and
> CSR generation. The most secure method is to generate the keys on the
server
> and then use the CSR when requesting the certificate. If you do generate
> private keys for any of your customers outside of the web server
environment
> where the certificate will be hosted, we request that you stop this
practice
> immediately.
> 
> We ask that all Partners and Resellers complete the following short
> questionnaire as soon as possible or by: Friday, March 16, 2018.
> 
> Compliance questionnaire : [REDACTED]
> Note: Only one questionnaire needs to be completed per company.
> 
> Thank you in advance for your cooperation and attention to this important
> topic.
> 
> Kind regards,
> GlobalSign Security and Compliance
> 
> 
> So it's nice to see that at least one CA is taking action on this topic
without
> being ordered to (that I'm aware of). Obviously not all resellers are like
Trustico
> and perform only a straight certificate pass-through, as Ryan Sleevi
pointed
> out, and key escrow is a necessary part of acting as a host, or CDN, or
other
> authorized representative.
> 
> But surely there is still some way to responsibly look through the
ecosystem for
> resellers that do not perform an authorized function that requires key
escrow.
> Are any other CAs willing to do something like GlobalSign has done?
> 
> Also, it would be very helpful if GlobalSign could share some information
> relating to the responses they get, even if they are aggregated or
anonymized.
> 
> -- Eric
> 
> On Sun, Mar 4, 2018 at 4:04 PM, Eric Mill  wrote:
> 
> > Last week, Trustico (a reseller, formerly for Symantec and now for
> > Comodo) sent 23,000 private keys to DigiCert, to force their
> > revocation. This showed that Trustico had been storing customer keys
> > generated through one or more CSR/key generation forms on their website.
> >
> > Though Trustico disagrees, this appears to be a clear case of routine
> > key compromise for subscribers who obtained their key from Trustico.
> > The security of Trustico's systems, which are not audited or
> > accountable to root program requirements, were storing large amounts
> > of key material whose compromise could have led to the subsequent
> > compromise of connections to tens of thousands of online services.
> >
> > It was also noted that Trustico was exposing key material to
> > interception by a number of third parties through client-side
> > JavaScript embeds, and that Trustico's website had functionality that
> > allowed remote code execution as root on one of their web servers.
> >
> > These m.d.s.p threads document/link to those things:
> >
> > * https://groups.google.com/d/topic/mozilla.dev.security.
> > policy/wxX4Yv0E3Mk/discussion
> > * https://groups.google.com/d/topic/mozilla.dev.security.
> > policy/BLvabFwcJqo/discussion
> >
> > As part of the second thread, Comodo noted:
> >
> > We also asked Trustico to cease offering any tools to generate and/or
> > retain customer private keys.  They have complied with this request
> > and have confirmed that they do not intend to offer any such tools
> > again in the future.
> >
> >
> > That is good to hear, but a "we won't do it again" response, if
> > accepted by Comodo as sufficient, seems disproportionate to the
> > severity of the issue, given Trustico's unfamiliarity with norms
> > around private key management, and with basic security practices.
> >
> > It's also clear from the experience that rules of the road for
> > resellers are unclear, and that accountability is limited. It seems
> > possible, or likely, that other resellers may also be mishandling
> > customer keys
> >
> > So, what would useful next steps be to improve security and
> > accountability for resellers?
> >
> > One thought: Mozilla could ask CAs to obtain a written response from
> > all contracted resellers about if/how they interact with customer key
> > material, including the level of iso

RE: Allowing WebExtensions to Override Certificate Trust Decisions

2018-02-27 Thread Tim Hollebeek via dev-security-policy
Wow, this is a tough one.  I've wanted to write such an extension myself for
quite some time.  In fact, I probably would write one or more extensions, if 
Mozilla were to allow this, for a variety of use cases.
 
That said, such extensions are extremely dangerous, and users are just going
to accept any warning that might exist about using such an extension.  But I
don't think designing for the ignorant and clueless is wise.  You'll just find
better idiots.

I personally find persuasive the argument that an extension already has the
ability to do equivalently bad things.  The research group I used to work with
many years ago did lots of work with application extensions of all kinds, and
web extensions in particular were obscenely powerful because of the very
rich structure of the Document Object Model.

I'm sure (I hope!) things have been tightened up at least a little bit since 
then,
but I think in the presence of a malicious extension, the question of whether
it can affect the connection UI is rather moot.  Naïve users are going to lose
to a malicious extension every time, no matter what, and I seriously doubt
that even sophisticated users will have much of a chance in such scenarios,
whether the connection UI can be changed by the extension, or not.

It's probably useful to discuss this in conjunction with what controls Mozilla
has available in its ecosystem to combat malicious extensions in general,
as opposed to this particular case, which doesn't seem to be very special.
That more general question might lead to good principles that can be
applied in this specific situation.

Basically, I think it's a question of what the security model/policy for
extensions should be, how to balance the risks vs benefits of various pieces of
exposed functionality.  The tension between powerful, open APIs and
limited, but safer APIs has existed forever, and there isn't one point on
the spectrum that is optimal.

We recently had a case internally where some Office automation was not
possible due to some ad hoc restrictions imposed during the ILOVEYOU
era.  Addressing security risks piecemeal instead of holistically generally
results in a random set of arbitrary restrictions instead of a coherent
security model.  Figure out what the security policy and security model
is, and it will tell you whether allowing extensions to modify the connection
UI is ok.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Tuesday, February 27, 2018 9:21 AM
> To: mozilla-dev-security-policy 
> 
> Subject: Allowing WebExtensions to Override Certificate Trust Decisions
> 
> I am seeking input on this proposal:
> 
> Work is underway to allow Firefox add-ons to read certificate information via
> WebExtensions APIs [1]. It has also been proposed [2] that the WebExtensions
> APIs in Firefox be enhanced to allow a 3rd party add-on to change or ignore 
> the
> normal results of certificate validation.
> 
> This capability existed in the legacy Firefox extension system that was
> deprecated last year. It was used to implement stricter security mechanisms
> (e.g. CertPatrol) and to experiment with new mechanisms such as Certificate
> Transparency and DANE.
> 
> When used to override a certificate validation failure, this is a dangerous
> capability, and it’s not clear that requiring a user to grant permission to 
> the
> add-on is adequate protection. One solution that has been proposed [4] is to
> allow an add-on to affect the connection but not the certificate UI.
> In other words, when a validation failure is overridden, the page will load 
> but
> the nav bar will still display it as a failure.
> 
> I would appreciate your constructive feedback on this decision. Should this
> capability be added to the Firefox WebExtensions APIs?
> 
> - Wayne
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
> [3] https://mail.mozilla.org/pipermail/dev-addons/2018-
> February/003629.html
> [4] https://mail.mozilla.org/pipermail/dev-addons/2018-
> February/003641.html
> ___
> 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


RE: Google OCSP service down

2018-02-25 Thread Tim Hollebeek via dev-security-policy
Ryan,

Wayne and I have been discussing making various improvements to 1.5.2
mandatory for all CAs.  I've made a few improvements to DigiCert's CPSs in
this area, but things probably still could be better.  There will probably be
a CA/B ballot in this area soon.

DigiCert's 1.5.2 has our support email address, and our Certificate Problem 
Report email (which I recently added).  That doesn't really cover everything 
(yet).

It looks like GTS 1.5.2 splits things into security (including CPRs), 
non-security
requests.

I didn't chase down any other 1.5.2's yet, but it'd be interesting to hear what
other CAs have here.  I suspect most only have one address for everything.

Something to keep in mind once the CA/B thread shows up.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Hurst via dev-security-policy
> Sent: Wednesday, February 21, 2018 9:53 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Google OCSP service down
> 
> I wanted to follow up with our findings and a summary of this issue for the
> community.
> 
> Bellow you will see a detail on what happened and how we resolved the issue,
> hopefully this will help explain what hapened and potentially others not
> encounter a similar issue.
> 
> Summary
> ---
> January 19th, at 08:40 UTC, a code push to improve OCSP generation for a
> subset of the Google operated Certificate Authorities was initiated. The 
> change
> was related to the packaging of generated OCSP responses. The first time this
> change was invoked in production was January 19th at 16:40 UTC.
> 
> NOTE: The publication of new revocation information to all geographies can
> take up to 6 hours to propagate. Additionally, clients and middle-boxes
> commonly implement caching behavior. This results in a large window where
> clients may have begun to observe the outage.
> 
> NOTE: Most modern web browsers “soft-fail” in response to OCSP server
> availability issues, masking outages. Firefox, however, supports an advanced
> option that allows users to opt-in to “hard-fail” behavior for revocation
> checking. An unknown percentage of Firefox users enable this setting. We
> believe most users who were impacted by the outage were these Firefox users.
> 
> About 9 hours after the deployment of the change began (2018-01-20 01:36
> UTC) a user on Twitter mentions that they were having problems with their
> hard-fail OCSP checking configuration in Firefox when visiting Google
> properties. This tweet and the few that followed during the outage period were
> not noticed by any Google employees until after the incident’s post-mortem
> investigation had begun.
> 
> About 1 day and 22 hours after the push was initiated (2018-01-21 15:07 UTC),
> a user posted a message to the mozilla.dev.security.policy mailing list where
> they mention they too are having problems with their hard-fail configuration 
> in
> Firefox when visiting Google properties.
> 
> About two days after the push was initiated, a Google employee discovered the
> post and opened a ticket (2018-01-21 16:10 UTC). This triggered the
> remediation procedures, which began in under an hour.
> 
> The issue was resolved about 2 days and 6 hours from the time it was
> introduced (2018-01-21 22:56 UTC). Once Google became aware of the issue, it
> took 1 hour and 55 minutes to resolve the issue, and an additional 4 hours and
> 51 minutes for the fix to be completely deployed.
> 
> No customer reports regarding this issue were sent to the notification
> addresses listed in Google's CPSs or on the repository websites for the 
> duration
> of the outage. This extended the duration of the outage.
> 
> Background
> --
> Google's OCSP Infrastructure works by generating OCSP responses in batches,
> with each batch being made up of the certificates issued by an individual CA.
> 
> In the case of GIAG2, this batch is produced in chunks of certificates issued 
> in
> the last 370 days. For each chunk, the GIAG2 CA is asked to produce the
> corresponding OCSP responses, the results of which are placed into a separate
> .tar file.
> 
> The issuer of GIAG2 has chosen to issue new certificates to GIAG2 
> periodically,
> as a result GIAG2 has multiple certificates. Two of these certificates no 
> longer
> have unexpired certificates associated with them. As a result, and as 
> expected,
> the CA does not produce responses for the corresponding periods.
> 
> All .tar files produced during this process are then concatenated with the -
> concatenate command in GNU tar. This produces a single .tar file containing 
> all
> of the OCSP responses for the given Certificate Authority, then this .tar 
> file is
> distributed to our global CDN infrastructure for serving.
> 
> A change was made in how we batch these responses, specifically instead of
> outputting many .tar files within a batch, a concatenation was of all tar 

RE: Mozilla’s Plan for Symantec Roots

2018-02-13 Thread Tim Hollebeek via dev-security-policy

> OK. I'm researching what approach should be used for the Fedora Linux
> distribution, where a single CA trust list (based on Mozilla's CA trust
> list) is used for the whole system, including Firefox, and other 
> applications that
> use other certificate validation logic, like the ones built into the GnuTLS, 
> NSS
> and OpenSSL libraries.

FWIW, I realize we are where we are, but it's high time people started 
migrating
away from the concept of a single operating system trust list that is consumed
by all applications on the platform.  It just doesn't work very well since 
each
application type has its own unique security considerations, risks, and 
challenges.
And threat model, risk tolerance, value of data being protected, necessary
assurance level, etc etc etc.

It's ok to rely heavily on other trust stores to assist with bootstrapping or
maintaining a trust store, and this can even be codified directly into the new
trust store's policy.  For example, this is the approach taken by Cisco whose
trust store policy is basically the union of what's trusted by other major 
trust
stores.  It's a good baby step towards establishing an independent and well
maintained trust store.

Major trust stores have taken various actions nudging certificate authorities 
to
use a combination of technical constraints and/or EKUs and/or different
intermediate CAs in order to better segregate certificates by use case, and 
I'd
encourage them to continue with those efforts.  The current situation is a bit
of a mess, and it will take us years to get it all untangled.

-Tim




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


RE: Misissuance/non-compliance remediation timelines

2018-02-07 Thread Tim Hollebeek via dev-security-policy
Alex,

 

Most CAs probably wouldn’t aim for an A.  I don’t think doing this would be a 
game changer.

 

However there are some CAs that would.  And I think that would be a positive 
thing, and lead to more innovation in best practices that could become 
mandatory for everyone over time.

 

And I don’t disagree with you that action is needed on those who are currently 
getting Ds.  I’m very disturbed by the behavior of about half of the CAs in the 
industry.

 

-Tim

 

From: Alex Gaynor [mailto:agay...@mozilla.com] 
Sent: Wednesday, February 7, 2018 8:15 AM
To: Tim Hollebeek 
Cc: Paul Kehrer ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Misissuance/non-compliance remediation timelines

 

Hey Tim,

 

A piece I think I'm missing is what you see as the incentive for CAs to aim for 
an "A" rather than being happy to have a "B". It reminds me of the old joke: 
What do you call the Dr^W CA who graduated with a C average? Dr.^W trusted to 
assert www-wide identity :-)

 

That said, given the issues Paul highlighted in his original mail (which I 
wholeheartedly concur with), it seems the place to focus is the folks who are 
getting Ds right now. Therefore I think the essential part of your email is 
your agreement that CAs which are persistently low performing need to be 
recognized and potentially penalized for the sum total of their behaviors.

 

Alex

 

On Tue, Feb 6, 2018 at 8:30 PM, Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Paul,

I understand your frustration.  I've read some of the recent threads about
"how long does it take to update a CPS?" and clearly there needs to be
some stronger compliance language in either the BRs or Mozilla policy
("CAs MUST be able to update their CPS within 90 days").  And as you note
such policies need to have teeth otherwise there will be some who will
just ignore them.

However  negative penalties are not the only thing that should be
considered.
Mozilla should also have some way of recognizing CAs that are performing
above and beyond the minimum requirements.  I would love to see Mozilla
encourage CAs to compete to be the best CA in Mozilla's program.

To satisfy both goals, I'd like to suggest an idea I've had for a while: at
some
point in time (annually?), Mozilla should assess their opinion of how well
each CA in the program is performing, and give them a letter grade.  This
could include policy improvements like "Two consecutive failing grades,
or three consecutive C or lower grades and you're out of the Mozilla
program."

This would not preclude other actions as Mozilla deems necessary.  But it
would provide a regular checkpoint for CAs to understand either "Hey,
you're great, keep up the good work!" or "Meh, we think you're ok." or
"Your performance to date is unacceptable.  Get your sh*t together or
you're gone."

-Tim


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy- 
> <mailto:dev-security-policy-> 
> bounces+tim.hollebeek=digicert@lists.mozilla.org 
> <mailto:digicert@lists.mozilla.org> ] On Behalf Of Paul
> Kehrer via dev-security-policy
> Sent: Tuesday, February 6, 2018 6:03 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org 
> <mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
> Subject: Misissuance/non-compliance remediation timelines
>
> A bit over 5 months ago I reported a series of OCSP responders that were
> violating BRs (section 4.9.10) by returning GOOD on unknown serial
numbers.
> Since that time the majority of those responder endpoints have been fixed,
but
> several are still non-compliant; either with little communication or
continuing
> assurances that it will be fixed "soon", where soon is a date that
continuously
> slides into the future.
>
> At the moment Mozilla possesses very few options when it comes to punitive
> action and the lesson some CAs appear to be learning is that as long as
you
> don't rise to PROCERT levels of malfeasance/incompetence then the maximum
> penalty is censure on bugzilla and email threads. Clearly this is not a
deterrent.
>
> So, how long is too long? At what point should a CA incur consequences
(and
> what form can those consequences take) for failure to remediate despite
being
> given such immense latitude?
>
> As a straw man: what if we developed a set of technical constraints
related to
> minimizing risk associated with CAs that are deemed to be acting poorly?
> For example, CAs deemed a risk would have their certificate maximum
lifetime
> constrained to some amount less than the BRs currently allow.
> Additional penalties could include removal of EV trust indicators,
constraining
> trust to a limited set of domains, markin

RE: Misissuance/non-compliance remediation timelines

2018-02-07 Thread Tim Hollebeek via dev-security-policy
That’s pretty much exactly not what I said.

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, February 6, 2018 10:38 PM
To: Tim Hollebeek 
Cc: Paul Kehrer ; 
mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com
Subject: Re: Misissuance/non-compliance remediation timelines

 

So your view is the “carrot” is getting to use Mozilla’s brand as an 
endorsement, and the “stick” being that if you don’t get that endorsement for a 
while, you get kicked out?

 

The assumption is that the branding of “best” is valuable - presumably, through 
the indirect benefit of being able to appeal to customers as “the highest rated 
(by Mozilla) CA”.

 

In practice, much like the CA/Browser Forum indirectly gave birth to the CA 
“Security” Council, or the existence of firms like Netcraft or NSS Labs, the 
more common outcome seems to be that if you don’t like the rules of the game 
you’re playing, you make up your own/redefine them and try to claim equivalency 
(much lol “alternative facts”). That is, I’m skeptical of approaches that 
attempt to say “most good,” because those seem to encourage all sorts of games 
of coming up with their own schemes, while “least bad” is more actionable - as 
“most bad” is more likely to receive sanctions.

 

On Tue, Feb 6, 2018 at 10:03 PM Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Absolutely not.  I view the competition as being based as the “most best”.



You cannot get an “A” (or even A- or B+) without significantly exceeding the 
minimum requirements, or demonstrating behaviors and practices that, while not 
required, are behaviors Mozilla wants to encourage.



Sticks are good.  Carrots are tasty.



-Tim



Do you see the competition based on being the 'least bad' (i.e. more likely to 
get an A because of no issues than a B because of some?)

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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


RE: Misissuance/non-compliance remediation timelines

2018-02-06 Thread Tim Hollebeek via dev-security-policy
Absolutely not.  I view the competition as being based as the “most best”.

 

You cannot get an “A” (or even A- or B+) without significantly exceeding the 
minimum requirements, or demonstrating behaviors and practices that, while not 
required, are behaviors Mozilla wants to encourage.

 

Sticks are good.  Carrots are tasty.

 

-Tim

 

Do you see the competition based on being the 'least bad' (i.e. more likely to 
get an A because of no issues than a B because of some?)



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


RE: Misissuance/non-compliance remediation timelines

2018-02-06 Thread Tim Hollebeek via dev-security-policy
Paul,

I understand your frustration.  I've read some of the recent threads about 
"how long does it take to update a CPS?" and clearly there needs to be 
some stronger compliance language in either the BRs or Mozilla policy
("CAs MUST be able to update their CPS within 90 days").  And as you note
such policies need to have teeth otherwise there will be some who will
just ignore them.

However  negative penalties are not the only thing that should be
considered.
Mozilla should also have some way of recognizing CAs that are performing
above and beyond the minimum requirements.  I would love to see Mozilla
encourage CAs to compete to be the best CA in Mozilla's program.

To satisfy both goals, I'd like to suggest an idea I've had for a while: at
some
point in time (annually?), Mozilla should assess their opinion of how well
each CA in the program is performing, and give them a letter grade.  This
could include policy improvements like "Two consecutive failing grades,
or three consecutive C or lower grades and you're out of the Mozilla 
program."

This would not preclude other actions as Mozilla deems necessary.  But it
would provide a regular checkpoint for CAs to understand either "Hey,
you're great, keep up the good work!" or "Meh, we think you're ok." or
"Your performance to date is unacceptable.  Get your sh*t together or
you're gone."

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Paul
> Kehrer via dev-security-policy
> Sent: Tuesday, February 6, 2018 6:03 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Misissuance/non-compliance remediation timelines
> 
> A bit over 5 months ago I reported a series of OCSP responders that were
> violating BRs (section 4.9.10) by returning GOOD on unknown serial
numbers.
> Since that time the majority of those responder endpoints have been fixed,
but
> several are still non-compliant; either with little communication or
continuing
> assurances that it will be fixed "soon", where soon is a date that
continuously
> slides into the future.
> 
> At the moment Mozilla possesses very few options when it comes to punitive
> action and the lesson some CAs appear to be learning is that as long as
you
> don't rise to PROCERT levels of malfeasance/incompetence then the maximum
> penalty is censure on bugzilla and email threads. Clearly this is not a
deterrent.
> 
> So, how long is too long? At what point should a CA incur consequences
(and
> what form can those consequences take) for failure to remediate despite
being
> given such immense latitude?
> 
> As a straw man: what if we developed a set of technical constraints
related to
> minimizing risk associated with CAs that are deemed to be acting poorly?
> For example, CAs deemed a risk would have their certificate maximum
lifetime
> constrained to some amount less than the BRs currently allow.
> Additional penalties could include removal of EV trust indicators,
constraining
> trust to a limited set of domains, marking contexts as insecure, and
finally full
> distrust. Once a CA lands in a risk category further misissuance would
escalate
> their risk to the community and thus incur additional constraints. (I'm
sure the
> community can come up with far better tiers than I have!)
> 
> Adding controls like this will require significant time and effort from
Mozilla,
> but if we want to be able to manage the significant and ongoing volume of
> misissuance/non-compliance we're seeing I believe some level of
granularity is
> needed.
> 
> -Paul (reaperhulk)
> ___
> 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


RE: IP Validation using method 3.2.2.5 (4) "any other method"

2018-01-30 Thread Tim Hollebeek via dev-security-policy
Good point.  If you want your method preserved, please send it to one of the 
CA/Browser forum lists.



-Tim



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Tuesday, January 30, 2018 8:46 AM
To: Tim Hollebeek 
Cc: mozilla-dev-security-policy 

Subject: Re: IP Validation using method 3.2.2.5 (4) "any other method"







On Tue, Jan 30, 2018 at 10:37 AM, Tim Hollebeek via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:



I'm sending this to this list because CAs are required to monitor this list,
and I need to get feedback from smaller and more obscure CAs.



The validation working group is thinking about proposing removal of 3.2.2.5
(4) in the near future.  If you are currently using that method to validate
IP certificates, please reply with the details of what you are doing so the
procedure can be examined and potentially added to the Baseline Requirements
as a valid method for validating IP certificates.  FAILURE TO DO SO MAY
RESULT IN YOUR METHOD BECOMING NON-COMPLIANT WITH LITTLE OR NO NOTICE.



Just a note: Replying with those details to *this* list won't offer the 
CA/Browser Forum's IP protections.



I would instead suggest that CAs that do not participate in the CA/Browser 
Forum, but use this method, join the CA/Browser Forum and contribute such 
methods. The failure to disclose in a way that is agreed upon by the IP policy 
of the CA/Browser Forum is a reasonably high enough risk that it should be 
prevented from adding it to the CA/Browser Forum documents.





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


IP Validation using method 3.2.2.5 (4) "any other method"

2018-01-30 Thread Tim Hollebeek via dev-security-policy
 

I'm sending this to this list because CAs are required to monitor this list,
and I need to get feedback from smaller and more obscure CAs.

 

The validation working group is thinking about proposing removal of 3.2.2.5
(4) in the near future.  If you are currently using that method to validate
IP certificates, please reply with the details of what you are doing so the
procedure can be examined and potentially added to the Baseline Requirements
as a valid method for validating IP certificates.  FAILURE TO DO SO MAY
RESULT IN YOUR METHOD BECOMING NON-COMPLIANT WITH LITTLE OR NO NOTICE.

 

Thank you,

 

-Tim



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


  1   2   >