Hi Rich,
On 18/08/17 12:51, richmoor...@gmail.com wrote:
> Perhaps some explicit statements about sub-CAs would be helpful -
> detailing where responsibility lies and how a CA is required to deal
> with a sub-CA who is found to have misissued.
Do you specifically mean sub-CAs which are run by
On 18/08/17 13:03, Doug Beattie wrote:
> And if there is any guidance on processing misissuance reports for
> Name constrained sub-CA vs. not name constrained, that would be
> helpful also.
What parts of a response do you think might be different for
name-constrained sub-CAs?
Gerv
On 03/05/17 16:45, Peter Kurrasch wrote:
> Perhaps a different way to pose the questions here is whether Mozilla
> wants to place any expectations on the CA's regarding fraud and the
> prevention thereof.
You need to be more specific, because there are lots of different ways a
system can have
Hi Steve,
On 02/05/17 18:39, Steve Medin wrote:
> Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to
> respond to your latest proposal shortly.
Please understand that this is not (yet) Mozilla's response to Symantec.
If we were a closed root program, this would be an
Symantec have supplied the audits for their GeoRoot partner "Aetna":
https://bug1334377.bmoattachments.org/attachment.cgi?id=8867397
https://bug1334377.bmoattachments.org/attachment.cgi?id=8867398
The community might find them interesting reading. These audits are the
only ones Symantec received
On 15/05/17 12:54, Kurt Roeckx wrote:
> At least it's technically constrained.
Ah yes, you are right. Not nearly such an issue, then.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
Hi all,
One of the CA Communication questions was about the Problem Reporting
Mechanisms that CAs are supposed to have. The answers are here:
https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028
I would love it if someone would
On 12/05/17 09:18, Cory Benfield wrote:
> I try not to decide whether there is interest in features like this:
> if they’re easy I’d just implement them and let users decide if they
> want it. That’s what I’d be inclined to do here. If Mozilla added
> such a flag, I’d definitely be open to adding
With two exceptions (neither of which have the websites trust bit set),
all answers are now in from the April 2017 CA Communication. You can
find links to the answers here:
https://wiki.mozilla.org/CA/Communications#April_2017_Responses
Some highlights for the community's attention:
* (Q1) It
On 15/05/17 14:07, Jakob Bohm wrote:
> 1. Microsoft's e-mail clients were very late to accept stronger
> signature algorithms for e-mails (including e-mails sent by users of
> non-problematic e-mail clients). I believe Globalsign's page about
> SHA256-transition for customers provides a
On 09/05/17 18:25, Doug Beattie wrote:
> I'm not clear on what you mean by CAs must use only the 10 Blessed Methods by
> 21st July 2017.
>
> I'm assuming this is the latest official draft:
>
> https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
Yes :-)
> Specifically, does
On 08/05/17 13:24, Gervase Markham wrote:
> 8) Please explain how the Management Assertions for your December 2014
Strike this question; it's based on a misunderstanding of how audits are
done.
Let's add:
10) Do you agree that, during the period of time that Symantec
cross-signed the Federal
On 10/05/17 18:12, userwithuid wrote:
> Limiting to 60 months could be done right now as a sanity check and shouldn't
> cause any problems, right?
https://bugzilla.mozilla.org/show_bug.cgi?id=908125 .
Gerv
___
dev-security-policy mailing list
Dear Steve and Rick,
This is an official communication from the Mozilla CA program requesting
Symantec's answers to the following questions by close of business on
Monday 15th May. Your answers will be posted in
mozilla.dev.security.policy if you don't put them there yourselves. Your
speedy
Hi Cory,
On 11/05/17 15:21, Cory Benfield wrote:
> While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily.
Unfortunately, this is not a good enough reason to remove graduate trust
proposals from our arsenal of
On 11/05/17 13:02, wiz...@ida.net wrote:
> That said, it is fair point that the plan should spell out what happens if
> symantec does not cooperate.
I think we should cross that bridge when we come to it, which I hope we
won't. Not that I'm not prepared to cross it, but there's no point
On 11/05/17 12:46, Rob Stradling wrote:
> There's a "Created by" field (Username, Timestamp) and a "Last Modified
> By" field (Username, Timestamp) in the CCADB, but neither of these
> fields are currently provided in the public CSV reports that Mozilla
> publishes.
Rob: do you think you could
On 11/05/17 18:05, Alex Gaynor wrote:
> I don't think Cory's arguing against browsers making use of these types of
> remediations, he just wants the non-browser clients to be able to
> participate as well :-)
Sure. I'm just heading off that argument at the pass :-)
Gerv
On 08/05/17 16:50, Kurt Roeckx wrote:
> So all of them except those from 2017-05-05 should have been marked in
> the Common CA Database as revoked but haven't been marked as such.
Thank you. I have drawn this to the attention of the 3 CAs concerned and
asked them to post here to indicate when
Hi everyone,
Yesterday was May 8th, which was the day I had said we would stop
discussing my proposal of what to do about Symantec and hand it over to
Kathleen for a decision. This didn't happen for two reasons: I had some
personal things to deal with, and also I think the proposal needs some
On 01/05/17 10:09, Gervase Markham wrote:
> This simply involves changing a "2.0" to "2.2" in section 3.1.1 and
> updating the URL labelled "WebTrust-BRs" to be
> http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf .
Done.
Gerv
___
On 01/05/17 10:02, Gervase Markham wrote:
> Here is a diff of the proposed changes:
> https://github.com/mozilla/pkipolicy/compare/issue-57
Incorporated.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 16/05/17 18:04, Jakob Bohm wrote:
> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
>
> 1. The date restrictions on WoSign-issued certificates.
>
> 2. The EV trust bit for some CAs.
I am surprised you are engaging in a
On 16/05/17 02:26, userwithuid wrote:
> After skimming the responses and checking a few CAs, I'm starting to
> wonder: Wouldn't it be easier to just add another mandatory field to
> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
> policy and just use that to provide a public
On 17/05/17 15:08, Rob Stradling wrote:
> Incidentally, it's true that Mozilla have said that they don't care
> about the Code Signing trust bit any more, but the
> CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug?
Yes, but a low priority one. Feel free to file :-)
Gerv
On 17/05/17 13:32, Rob Stradling wrote:
> I've just added two columns to
> https://crt.sh/mozilla-disclosures#undisclosed:
> - "Earliest SCT".
> - "Listed Here Since".
Lovely! Now we just need a cert to be on the list so we can see what it
looks like ;-)
Gerv
On 17/05/17 12:55, Jakob Bohm wrote:
> That is /human readable/ information, not /computer readable/ data that
> can be imported by other libraries when those are used with the Mozilla
> root program.
Yes, indeed. But you asked where in certdata.txt those things are, and
that page explains pretty
Mozilla's Enforcement Policy indicates what to do when a serious
security concern is noticed, but does not indicate what to do when a
lesser security concern is noticed.
The current text is now in section 7, and says:
"Changes that are motivated by a serious security concern such as a
major root
Mozilla policy requires that certificates issued in contravention of a
CA's CP/CPS should be revoked. Other than that, Mozilla policy does not
directly require that a CA operate in accordance with its CP and CPS. We
require this indirectly because the audits that we require, require it.
This
On 15/05/17 14:19, Doug Beattie wrote:
> https://support.globalsign.com/customer/portal/articles/1216323
Thanks, Doug. There's no date on that doc - are you able to say when it
was written?
Gerv
___
dev-security-policy mailing list
On 01/05/17 10:13, Gervase Markham wrote:
> This would involve replacing section 2.2.3 of the policy with:
Incorporated as drafted. CAs should take note (from this change and from
the CA Communication) that Mozilla's policy is moving in the direction
of requiring the 10 Blessed Methods alone,
On 07/06/17 22:30, Jakob Bohm wrote:
> Potential clarification: By "New PKI", Mozilla apparently refers to the
> "Managed CAs", "Transition to a New Symantec PKI" and related parts of
> the plan, not to the "new roots" for the "modernized platform" / "new
> infrastructure".
I expect those things
On 08/06/17 10:17, Gervase Markham wrote:
> What downsides would there be, other than the obvious "some sites might
> break", to us just adding any such intermediate certs directly to OneCRL?
We provide reports which allow CAs to download the stored intermediate
cert data:
On 06/06/17 19:59, Jakob Bohm wrote:
> I don't see a problem in access to this being subject to a reasonable
> NDA that allows Mozilla to show it to their choice of up to 50 external
> experts (I don't expect to be one of those 50).
The problem with an NDA is that if the audit reports significant
On 08/06/17 00:42, Jonathan Rudenberg wrote:
> Yet another batch of undisclosed intermediates has shown up in CT:
Like, seriously?
Every CA in our program indicated that they would disclose all their
intermediates by June 30th, 2016:
On 02/06/17 11:28, Gervase Markham wrote:
> Proposal: add a bullet to section 2.3, where we define BR exceptions:
>
> "Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (section 1.1) overrides that. Mozilla expects
> CA operations relating to
On 07/06/17 06:14, userwithuid wrote:
> 2. Having Symantec inform their subscribers, as David mentions, is a great
> idea.
I believe Ryan has pointed out, here or elsewhere, why "must notify
customers" requirements are problematic.
Gerv
___
Hi everyone,
I've made the last change I currently intend to make for version 2.5 of
Mozilla's Root Store Policy. The last task before shipping it is to
assess whether any of the changes require a phase-in period, i.e. for
some reason, they can't be applicable immediately.
CAs and others are
On 04/06/17 03:03, Matt Palmer wrote:
> For whatever it is worth, I am a fan of this way of defining "misissuance".
This is an "enumerating badness" vs. "enumerating goodness" question. My
original draft attempted to (without limitation) enumerate some badness,
and you and Ryan are suggesting
On 20/06/17 01:21, Jakob Bohm wrote:
> 2. For any certificate bundle that needs to be incorporated into the
> Mozilla root stores, a significant period (3 to 6 months at least)
> will be needed between acceptance by Mozilla and actual trust by
> Mozilla users.
Not if the roots were
Hi Doug,
On 20/06/17 16:31, Doug Beattie wrote:
> I'd like to recommend a phase in of the requirement for technically
> constrained CAs that issue Secure email certificates.
For those following along at home, that is this change:
https://github.com/mozilla/pkipolicy/issues/69
On 21/06/17 16:58, Doug Beattie wrote:
>> It's worth noting that if we had discovered this situation for SSL - that an
>> unconstrained intermediate or uncontrolled power of issuance had been
>> given to a company with no audit - we would be requiring the intermediate
>> be revoked today, and
On 21/06/17 13:13, Doug Beattie wrote:
>> Do they have audits of any sort?
>
> There had not been any audit requirements for EKU technically
> constrained CAs, so no, there are no audits.
In your view, having an EKU limiting the intermediate to just SSL or to
just email makes it a technically
Version 2.5 of Mozilla's CA Policy has now been published. You can
find it here:
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
This document incorporates by reference the Common CCADB Policy 1.0.1:
https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md
or
A few root store operators at the recent CAB Forum meeting informally
discussed the idea of a common format for root store information, and
that this would be a good idea. More and more innovative services find
it useful to download and consume trust store data from multiple
parties, and at the
I think it might be useful to take a step back and remind ourselves of
Mozilla's mission, principles and goals with regard to resolving the
situation with Symantec. These will be useful as we flesh out the
details of the consensus proposal, particularly concerning dates.
First, a quick reminder
On 27/06/17 07:17, Kurt Roeckx wrote:
> I suggest you keep it for now.
An opinion without a rationale is not all that useful :-)
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 27/06/17 10:35, Ryan Sleevi wrote:
> If that is the goal, it may be useful to know what the proposed limitations
> / dependencies are. For example, the translation of the txt to the c file
> generated non-trivial concern among the NSS development team to support.
I propose it be part of the
On 18/05/17 23:40, Nick Lamb wrote:
> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
> here? Judging from self-assessment document, TrustCor's actual
> practices are all intended to be 3.2.2.4 compliant (I will examine in
> more detail later) but the language here suggests it
Hi Doug,
On 18/05/17 12:03, Doug Beattie wrote:
> I'm still looking for audit guidance on subordinate CAs that have EKU
> of Server auth and/or Secure Mail along with name constraints. Do
> these need to be audited?
>
> I'm looking at this:
>
On 24/05/17 15:31, Peter Kurrasch wrote:
> It might be fair to characterize my position as "vague but
> comprehensive"...if that's even possible? There are some standard-ish
> frameworks that could be adopted:
I think we would prefer to wait for the CAB Forum to adopt something
rather than
At the moment, the CAB Forum's Network Security guidelines are audited
as part of an SSL BR audit. This means that CAs or sub-CAs which only do
email don't technically have to meet them. However, they also have a
number of deficiencies, and the CAB Forum is looking at replacing them
with something
On 19/05/17 15:28, Peter Bowen wrote:
> This is not accurate. They have indicated that the SSP customers have
> some level of issuance capability.
Oops. Well, they said that a while back, but yes indeed, since then we
have discovered the above fact.
Gerv
On 12/05/17 14:00, Gervase Markham wrote:
> Because the Mozilla root store is used by more people than Mozilla,
> Kathleen would like to put anyEKU in scope even though Firefox ignores it.
Implemented as specced.
Gerv
___
dev-security-policy mailing
On 12/04/17 10:47, Gervase Markham wrote:
> We don't have any "Email BRs" to refer to, but I think we want something
> like this:
>
> "If the certificate includes the id-kp-emailProtection extended key
> usage, it MUST include the Name Constraints X.509v3 extension with
> constraints on
We need to have a discussion about the appropriate scope for:
1) the applicability of Mozilla's root policy
2) required disclosure in the CCADB
The two questions are related, with 2) obviously being a subset of 1).
It's also possible we might decide that for some certificates, some
subset of the
Ryan Sleevi suggested a wording clarification/policy extension to the
multi-factor auth requirement, from:
"enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance"
to
"enforce multi-factor authentication for all accounts capable of causing
On 15/05/17 22:08, Michael Casadevall wrote:
> RA & EV:
> Were all the certificates issued by the RAs uploaded to a CT log? If
> not, what, if any, subsets were uploaded?
>
> I'm aware Symantec was required to upload certificates to CT or if it
> was retroactive, but I'm unsure if that requirement
On 19/05/17 15:16, Inigo Barreira wrote:
> What about those for gmail, Hotmail, etc.? Are out of scope?
I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they
can have one. They would presumably need to set the dirName to "" or
null, because no dirName can cover all of their
On 08/05/17 11:32, Dimitris Zacharopoulos wrote:
> On 8/5/2017 1:18 μμ, Gervase Markham wrote:
>>> + dirName entries scoped in the Organizational name and
>>> location
>> Help me understand how dirName interacts with id-kp-emailProtection?
>
> When the Subscriber belongs to an
On 15/05/17 21:06, Michael Casadevall wrote:
> Sorry, I could have been more clear here. What I'm proposing is that
> after a specific TBD NotBefore date, we require SCTs to be in place on
> the certificate to be trusted. Certificates from before that date
> would remain trusted as-is (pending any
On 12/05/17 14:21, Gervase Markham wrote:
> Specifically, we could add text to the top of section 5.2 ("Forbidden
> and Required Practices"):
>
> "CA operations MUST at all times be in accordance with the applicable CP
> and CPS."
Implemented as specced.
Gerv
On 19/05/17 15:52, Carl Mehner wrote:
> Should we specify somewhere that multi-factor auth encompasses two
> _different_ factors and not simply multiple authenticators?
I appreciate your desire to cover all the angles, but I think the
standard definition of the term encompasses this.
I think
On 19/05/17 20:40, Matthew Hardeman wrote:
> Not speaking as to the status quo, but rather in terms of
> updates/changes which might be considered for incorporation into
> policy would be to recognize the benefit of name constrained
> intermediates and allow a reduction in burden to entities
On 20/05/17 15:26, Michael Casadevall wrote:
> However, for Mozilla's purposes, is there a case where having a SCT in
> certificate would either break something, or otherwise be undesirable?
I believe we turned the checking on and discovered performance issues,
so we turned it off. I'm not sure
On 24/05/17 16:33, Peter Bowen wrote:
> Can you clarify the meaning of "new PKI"? I can see two reasonable
> interpretations:
> 2) The new PKI includes both new offline CAs that meet the
> requirements to be Root CAs and new subordinate CAs that issue
> end-entity certificates. the The new
On 26/05/17 01:01, Kathleen Wilson wrote:
> Known problems: - Some CAs did not provide their CAA (Certification
> Authority Authorization) information correctly, so that column is
> empty for them. Note that some CAs do not have the Websites trust bit
> set for any of their root certs, so that
Hi m.d.s.p.,
Google have posted their updated plan for Symantec in the blink-dev
forum (copied below).
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
Insofar as it pertains to Google's actions, you should go over and
discuss it there. But of course, this plan
On 19/05/17 16:06, Inigo Barreira wrote:
> Yes, I wanted to know if a regular user can use its Gmail account to get an
> s/mime cert but that can´t be issued because the CA can´t validate the
> domain properly because it´s not his or authorized to use it when doing the
> 3.2.2.4
This is about
On 19/05/17 14:26, Kurt Roeckx wrote:
> I'm wondering why something like this should be in the Mozilla policy
> and not be part of something else that they get audited for.
Section 6.5.1 of the BRs states:
"The CA SHALL enforce multi‐factor authentication for all accounts
capable of directly
On 23/05/17 04:18, Peter Kurrasch wrote:
> I think the term "industry best practices" is too nebulous. For
> example, if I patch some of my systems but not all of them I could
> still make a claim that I am following best practices even though my
> network has plenty of other holes in it.
I'm not
On 19/05/17 21:04, Kathleen Wilson wrote:
> - What validity periods should be allowed for SSL certs being issued
> in the old PKI (until the new PKI is ready)?
Symantec is required only to be issuing in the new PKI by 2017-08-08 -
in around ten weeks time. In the mean time, there is no
On 21/05/17 19:37, userwithuid wrote:
> With the new proposal, the "minimal disruption" solution for Firefox
> will require keeping the legacy stuff around for another 3.5-4 years
> and better solutions will now be a lot harder to sell without the
> leverage provided by Google.
Why so? In eight
On 22/05/17 16:43, Matthew Hardeman wrote:
> Regarding specifically the risk of the holder of a technically
> constrained subCA issuing a certificate with an SHA-1 signature or
> other improper signature / algorithm, my belief at this time is that
> with respect to the web PKI, we should be able
On 19/05/17 22:10, Jakob Bohm wrote:
> Necessity: Whitelists in various forms based on such CT log entries,
> as well as the SCTs in OCSP responses can provide an alternative for
> relying parties checking current certificates even if the cleanup at
> Symantec reveals a catastrophic breach
On 19/05/17 13:18, Gervase Markham wrote:
> Ryan Sleevi suggested a wording clarification/policy extension to the
> multi-factor auth requirement, from:
>
> "enforce multi-factor authentication for all accounts capable of
> directly causing certificate issuance"
>
> to
>
> "enforce multi-factor
On 01/06/17 13:59, Gervase Markham wrote:
> Perhaps this leads to the solution? We say:
>
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing RA or DTP functions as defined by the
> Baseline Requirements"
or "enforce multi-factor
On 19/05/17 14:47, Gervase Markham wrote:
> We need to have a discussion about the appropriate scope for:
>
> 1) the applicability of Mozilla's root policy
> 2) required disclosure in the CCADB
I've now reviewed the previous discussion we had on this topic, here:
It has been suggested we need a formal definition of what we consider
mis-issuance. The closest we have is currently a couple of sentence in
section 7.3:
"A certificate that includes domain names that have not been verified
according to section 3.2.2.4 of the Baseline Requirements is considered
The scope of the BRs is ambiguous, and almost certainly smaller than the
scope of the Mozilla policy. It might be useful to explicitly draw
attention to that fact, for the avoidance of doubt.
Proposal: add a bullet to section 2.3, where we define BR exceptions:
"Insofar as the Baseline
On 02/06/17 12:24, Kurt Roeckx wrote:
> Should that be "all certificates" instead of "all SSL certificates"?
No; the Baseline Requirements apply only to SSL certificates.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
Hi Steve,
I'm writing to you in your role as the Primary Point of Contact for
Symantec with regard to the Mozilla Root Program. I am writing with a
list of Mozilla-specific additions to the consensus remediation proposal
for Symantec, as documented by Google.
We note that you have raised a
On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com though
How would you like it if a CA decided there was nothing important on
your website and so decided it was OK to misissue certificates for it?
This requirement is a positive requirement ("must
On 31/05/17 18:02, Matthew Hardeman wrote:
> Perhaps some reference to technologically incorrect syntax (i.e. an
> incorrectly encoded certificate) being a mis-issuance?
Well, if it's so badly encoded Firefox doesn't recognise it, we don't
care too much (apart from how it speaks to
Hi Doug,
On 01/06/17 10:54, Doug Beattie wrote:
> Can you give some examples of validation functions that need to be enforced
> by multifactor authentication? There are some that I don't think can be done
> using multi-factor authentication, such as domain validation via email (the
> link to
On 01/06/17 13:45, Ryan Sleevi wrote:
> The reason why I don't think it's a valid reasoning is that if we accept
> that this provision in the policy could be read to cover such emails, then
> we're implicitly agreeing that the act of clicking that email is performing
> a validation function
On 19/05/17 13:55, Gervase Markham wrote:
> "CAs whose certificates are included in Mozilla's root program MUST:
> .
> * follow industry best practice for securing their networks, for example
> by conforming to the CAB Forum Network Security Guidelines or a
> successor document;"
Implemented
On 02/06/17 17:07, Peter Bowen wrote:
> Should Mozilla include a clear definition of "SSL certificates" in the
> policy? And should it be based on technical attributes rather than
> intent of the issuer?
Absolutely Yes to your second sentence :-). We do have a clear
definition of what's in
On 02/06/17 17:24, Kurt Roeckx wrote:
> On Fri, Jun 02, 2017 at 04:50:44PM +0100, Gervase Markham wrote:
>> On 02/06/17 12:24, Kurt Roeckx wrote:
>>> Should that be "all certificates" instead of "all SSL certificates"?
>>
>> No; the Baseline Requirements apply only to SSL certificates.
>
> Then I
On 02/06/17 12:29, Ryan Sleevi wrote:
> 2) "performing RA or DTP functions"
I'll go with that :-)
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 05/06/17 16:52, Matthew Hardeman wrote:
> Has there ever been an effort by the root programs to directly assess
> monetary penalties to the CAs -- never for inclusion -- but rather as
> part of a remediation program?
Another fact to bear in mind when discussing this is that, for a number
of
On 04/06/17 03:03, Matt Palmer wrote:
> For whatever it is worth, I am a fan of this way of defining "misissuance".
So you think we should use the word "misissuance" for all forms of
imperfect issuance, and then have a gradated reaction depending on the
type and circumstances, rather than use the
On 05/06/17 14:29, Alex Gaynor wrote:
> As I've expressed before, I find it baffling that this still happens.
I am also disappointed. I have half a mind to keep track of how often
this happens per CA, and impose a mandatory delay of 1 month per
incident to that CA's next attempt to include a new
Here are some thoughts from me:
On 06/06/17 15:02, Gervase Markham wrote:
> 1) Scope of Distrust
I have sought more information from Google on this.
> 2) Timeline
I think the question here is, what is our position, and on what basis do
we decide it? If we want to impose an aggressive but
On 09/06/17 16:37, Jakob Bohm wrote:
> This seems to directly violate the often proposed (but apparently not
> yet enacted) rule that different root certs must have different keys
> (if that rule has been incorporated into a current policy).
This has come up enough times now that I've filed an
On 09/06/17 11:29, Rob Stradling wrote:
> These two certs share the same Name and Key. Therefore, the signature
> on the first can be verified by the public key in the second; and vice
> versa. And clearly the Subject Name in each one matches the Issuer Name
> in the other. This means that the
On 08/06/17 19:46, Jakob Bohm wrote:
> How about the following, which seems more correct
Yes; I'm not sure why David thought the original version's two sentences
were contradicting rach other.
> Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy
On 08/06/17 15:37, Jeremy Rowley wrote:
> If you added them automatically to OneCRL, how would you create new
> intermediates? Would it be anything over X days old and undisclosed is
> automatically added?
Yes, that :-) Sorry if that wasn't clear. The deadline, as of policy
2.5, is a week
On 03/05/17 21:31, Han Yuwei wrote:
> A question:How would a domain holder express denial for certain certificate
> requests?
Please can you post new questions as new threads rather than as replies
to existing threads on another topic?
The answer to your question is that they can define which
On 05/05/17 18:58, Peter Bowen wrote:
>> Right now the policy does not require disclosure of CA-certificates
>> that the CA deems are technically constrained.
I believe this was made the case for some mix of the following reasons:
a) the CA did not want to reveal every customer it had;
b) this
201 - 300 of 431 matches
Mail list logo
