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 15:15, Rob Stradling wrote:
> Shall I add the same two fields to
> https://crt.sh/mozilla-disclosures#disclosureincomplete as well?
Yes, why not? :-)
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lis
On 17/05/17 15:49, Rob Stradling wrote:
> The "Listed Here Since" timestamps for the 24 intermediates currently in
> this category are set to today, because I don't have a time machine to
> go back and find out how long they've actually been listed in this
> category. ;-)
Lack of time machine is
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 mig
On 12/05/17 14:18, Gervase Markham wrote:
> I propose instead:
>
> "Changes that are motivated by a security concern such as certificate
> misissuance or a root or intermediate compromise MUST be treated as a
> security-sensitive, and a secure bug filed in Bugzilla.
Implemented as proposed.
Gerv
On 12/05/17 18:54, Jakob Bohm wrote:
> Perhaps tweak the wording to make the document submitted to the CCADB
> binding, rather than any CP/CPS published elsewhere.
While that certainly seems attractive, changing the location of the
canonical CP/CPS from the CA's repository to Mozilla's repository
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 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 lis
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
certifica
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 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 rfc822
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 Organizati
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
On 19/05/17 14:58, Jakob Bohm wrote:
> Because the O and other dirname attributes may be shown in an e-mail
> client (current or future) as a stronger identity than the technical
> e-mail address.
Do you know of any such clients?
> Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
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 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 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 caus
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 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 custom
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 tech
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 ha
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 tha
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 holdin
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 if
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 restrictio
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 during
On 19/05/17 22:16, Rob Stradling wrote:> Are you saying that Symantec
would be a Delegated Third Party that can
> perform all of the validation and can trigger certificate issuance, but
> that it would actually be a third-party CA that handles the new Symantec
> PKI and issues certs (when triggered
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 mo
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 to
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 14:12, Gervase Markham wrote:
> Updated language:
>
> "If the certificate includes the id-kp-emailProtection extended key
> usage, it MUST include the Name Constraints X.509v3 extension with
> constraints on rfc822Name, with at least one name in permittedSubtrees,
> each such name havi
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:
> https://github.com/mozilla/pkipolicy/blob/master/root
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 attempt
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 ro
Here's my roundup of things I think we should require of Symantec.
* Mozilla would wish, after 2017-08-08, to alter Firefox such that it
trusts certificates issued in the "new PKI" directly by embedding a set
of certs or trust anchors which are part of that PKI, and can therefore
distrust any 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 colu
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 a
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 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:
https://groups.google.com/forum/#
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
to
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 have
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 incompetence).
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 c
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 pursuan
On 01/06/17 13:49, Ryan Sleevi wrote:
> I would encourage you to reconsider this, or perhaps I've misunderstood
> your position. To the extent that Mozilla's mission includes "The
> effectiveness of the Internet as a public resource depends upon
> interoperability (protocols, data formats, content)
On 01/06/17 14:22, Doug Beattie wrote:
> If this is the case, then in what cases do you see 2-factor auth being a
> requirement where it was not before?
Well, Mozilla policy didn't require that all RA accounts had
multi-factor, only those directly capable of causing certificate
issuance. Maybe th
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 authent
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 Requiremen
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
Symantec have responded to the Google proposal (which Mozilla has
endorsed as the basis for further discussion) with a set of inline
comments which raise some objections to what is proposed.
Google will, no doubt,
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
ht
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 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 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 scope;
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 rea
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 r
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 02/06/17 15:53, Gervase Markham wrote:
> https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
I'm slightly surprised to see no engagement here. Perhaps it would be
help to break it down. Symantec's specific requests for modification are
as follows (my interpretatio
On 06/06/17 15:12, Alex Gaynor wrote:
> I suspect many of us are a bit exhausted by the discussion :-).
That's fair enough! :-) I can understand that.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.
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 achiev
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 number
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 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
___
dev-secur
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 t
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:
https://ccadb-public.secure.force.com/mozillacommunications/CA
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:
https://ccadb-public.se
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 that
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 issuan
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 requ
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 (se
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 (sectio
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 f
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 iss
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
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 cross-sig
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
https://github.com/
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 co
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 proba
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
http://ccadb.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 mom
This issue seems to come up regularly, and I can never find the
discussion I'm sure we had about it, so I'm starting a thread here with
"P-521" in the subject so it'll be clear.
Should we be permitting use of this curve in our policy?
I removed it from the policy in
https://github.com/mozilla/pki
On 26/06/17 17:36, Ryan Sleevi wrote:
> Do you anticipate this being used to build trust decisions in other
> products, or simply inform what CAs are trusted (roughly)?
I don't have strong opinions about what people use the data for; I would
hope it would be usable for either purpose. After all, p
On 27/06/17 04:16, Rob Stradling wrote:
> If the aim is to replace certdata.txt, authroot.stl, etc, with this new
> format, then I'm more interested.
I can't speak for other providers, but if such a spec existed, I would
be pushing for Mozilla to maintain our root store in that format, and
auto-ge
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
https://lists.mozilla.org/listinfo/dev-secu
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 che
On 27/06/17 12:17, Ryan Sleevi wrote:
> This was something the NSS developers explicitly moved away from with
> respect to certdata.c
It would be interesting to know the history of that; but we are in a
different place now in terms of the SCM system we use and the CI tools
available, versus what w
On 28/06/17 06:38, Ryan Sleevi wrote:
> Not really, at least from the NSS perspective. There's been the CVS ->
> Mercurial -> Git(ish) transitions, but otherwise, the tools and
> dependencies have largely remained the same.
Well, the fact that we now use Git, I suspect, means anyone could plug
in
On 28/06/17 15:08, Ryan Sleevi wrote:
> It already (effectively) requires a tool to make sure it's done right, AIUI :)
Well, we should ask Kai what methods he uses to maintain it right now,
and whether he uses a tool.
> You can have a JSON file, but that doesn't mean it's human-readable in the
>
On 29/06/17 00:11, Arkadiusz Ławniczak wrote:
> P-256, P-384 and P-521 curves are commonly implemented in all popular
> cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or
> Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware
> cryptographic modules.
Are
Hi Kai,
On 30/06/17 17:38, Kai Engert wrote:
> given that today we don't have a single place where all of Mozilla's
> certificate
> trust decisions can be found, introducing that would be a helpful.
I'm glad you see the value in my goal :-)
> I think the new format should be as complete as poss
Hi everyone,
As I was in the Bay Area for the Mozilla All Hands, Symantec requested a
face-to-face meeting with Mozilla, which happened last Friday. In
attendance were Tom Ritter, Aaron Wu and I for Mozilla, and the
following people from Symantec (I hope I have the titles right):
* Quentin Liu (H
Hi Peter,
I note you have copied in our press team and that you are a journalist;
I will answer your question as I would the same question from any member
of our community here if it were asked in this forum.
On 03/07/17 16:54, Loshin, Peter wrote:
> Other than stating that it will be publishing
On 03/07/17 17:29, Peter Bowen wrote:
> "name constraints which do not allow Subject Alternative Names (SANs)
> of any of the following types: dNSName, iPAddress, SRVName,
> rfc822Name"
>
> SRVName is not yet allowed by the CA/Browser Forum Baseline
> Requirements (BRs), so I highly doubt any CA h
On 03/07/17 17:44, Peter Bowen wrote:
> We still need to get the policy changed, even with the ballot. As
> written right now, all name constrained certificates are no longer
> considered constrained.
I'm not sure what you mean... What's the issue you are raising here?
Gerv
_
On 29/06/17 16:27, Ryan Sleevi wrote:
> Well, the current certdata.txt is a text file. Do you believe it's
> human-readable, especially sans-comments?
Human readability is, of course, a little bit of a continuum. You can
open it in a text editor and get some sense of what's going on, but it's
far
On 03/07/17 16:53, Kai Engert wrote:
> On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote:
>> On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote:
>>> Well, the fact that we now use Git,
>
> NSS and the root store don't use Git, it uses HG/Mercurial.
Y
On 03/07/17 16:09, Kai Engert wrote:
> I'd prefer a simple open source tool that operates on files, which can be used
> from a command line, with a free license, e.g. MPL2.
Of course.
> If the intention is to define a file format that is shared with other groups,
> who would be the owner of the f
I agree crypto algorithms are not "gotta catch 'em all", but the
algorithm is ECDH, which NSS must implement anyway to support P-256 and
P-384, and a curve is just another set of parameters to it. I also think
that there is little value and there is potential confusion (as we have
seen) in Mozilla
On 05/07/17 14:49, Alex Gaynor wrote:
> Is it really true that additional curves are just additional parameters? I
That was my assumption; additional clue on this point would be welcome.
Gerv
___
dev-security-policy mailing list
dev-security-policy@list
On 05/07/17 15:10, Peter Bowen wrote:
> The second bullet says “any”. As the rule for name constraints is that if
> they are not present for a type, then any name is allowed, you have to
> include name constraints for all four types. The issue comes down to the
> definition of “working server”
On 06/07/17 14:44, Kai Engert wrote:
> My response was based on my interpretation of Gerv's suggestion, which I
> understood as follows:
> - certdata.txt remains the master, keeps maintained and published with NSS
> - we define a new file format that's accepted as the standard for several
> root
201 - 300 of 500 matches
Mail list logo
