On Fri, Jan 18, 2019 at 10:34 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> How does this match the policy that a name constrained intermediate (1st
> intermediate) can be placed in the control of an organization that has
> been validated as controlling
ase of certificate chain.
(root cert)--(1st intermediate cert)--(2nd intermediate cert)--(EE cert)
In addition, "1st intermediate cert" is for technically constrained with
name constraints (including server-auth EKU).
I believe we Must put EKU (server-auth) for "2nd intermediate cert"
Thanks Sleevi
Thanks to provide us an example of (another intermediate).
Technical and name constraints seems much clear for me now.
2019年1月15日火曜日 1時56分58秒 UTC+9 Ryan Sleevi:
> On Mon, Jan 14, 2019 at 11:10 AM tadahiko.ito.public--- via
> dev-security-policy wrote:
>
> > Hi
Thanks Wayne
Thanks to break up requirements of not having name-constraints for 1st and 2nd
intermediate.
If we would not able to use name-constraints for some technical reason, we
might think about that idea.
Although, I believe our company do not have such a requirement at least now.
2019年
certificate chain.
> > (root cert)--(1st intermediate cert)--(2nd intermediate cert)--(EE cert)
> > In addition, "1st intermediate cert" is for technically constrained with
> > name constraints (including server-auth EKU).
> >
> > I believe we Must put EKU (se
" is for technically constrained with
> name constraints (including server-auth EKU).
>
> I believe we Must put EKU (server-auth) for "2nd intermediate cert".
> (regarding Mozilla root store policy 5.3)
> However, Does "2nd intermediate cert" need name constraints?
>
Hi
I have question for following case of certificate chain.
(root cert)--(1st intermediate cert)--(2nd intermediate cert)--(EE cert)
In addition, "1st intermediate cert" is for technically constrained with name
constraints (including server-auth EKU).
I believe we Must put E
in name constraints
On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley
wrote:
> I realize use of underscore characters was been debated and explained
> at the CAB Forum, but I think it's pretty evident (based on the certs
> issued and responses to Ballot 202) that not all CAs bel
definition of "SRVname" meant an otherName type
entry. Obviously a dNSName of _xmpp.example.com would have name
constraints applied, so I don't think that there is an issue there.
Thanks,
Peter
___
dev-security-policy mailing list
dev-s
On Behalf Of Peter Bowen via dev-security-policy
Sent: Tuesday, August 15, 2017 8:51 AM
To: Gervase Markham
Cc: Ryan Sleevi ; Peter Bowen ;
mozilla-dev-security-policy
Subject: Re: SRVNames in name constraints
On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via dev-security-policy
wrote:
> O
On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via
dev-security-policy wrote:
> On 06/07/17 16:56, Ryan Sleevi wrote:
>> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth)
>
> So what do we do? There are loads of "name-constrained" certs out there
> with id-kp-serverAuth but
On 06/07/17 16:56, Ryan Sleevi wrote:
> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth)
So what do we do? There are loads of "name-constrained" certs out there
with id-kp-serverAuth but no constraints on SRVName. Does that mean they
can issue for any SRVName they like? Is t
On Thu, Jul 6, 2017 at 10:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> What EKU(s) get used with certs containing SRVName? I confess I don't
> understand this technology as well as I might.
>
Relevant to this group, id-kp-serverAuth (and perhap
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 “wo
o prevent
issuance of working server or email certificates. Such technical constraints
could consist of either:
an Extended Key Usage (EKU) extension which does not contain any of these
KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or:
name constraints which do not allow S
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 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 (BR
3, 2017 10:30 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: SRVNames in name constraints
>
> In reviewing the Mozilla CA policy, I noticed one bug that is probably my
> fault. It says:
>
> "name constraints which do not allow Subject Alternative Name
en via dev-security-policy
Sent: Monday, July 3, 2017 10:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: SRVNames in name constraints
In reviewing the Mozilla CA policy, I noticed one bug that is probably my
fault. It says:
"name constraints which do not allow Subject Alternat
In reviewing the Mozilla CA policy, I noticed one bug that is probably
my fault. It says:
"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 Foru
t; From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve.roylance=globalsign@lists.mozilla.org] On Behalf Of
> Kathleen Wilson
> Sent: 18 November 2015 19:33
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Policy Update Proposal -- Refer to BRs for Na
On 11/5/15 11:00 AM, Kathleen Wilson wrote:
On 10/28/15 10:25 AM, Kathleen Wilson wrote:
Therefore, this proposal is modified to simplify item #9 of the
Inclusion Policy,
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
as follows:
~~
We encourage
On 10/28/15 10:25 AM, Kathleen Wilson wrote:
Therefore, this proposal is modified to simplify item #9 of the
Inclusion Policy,
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
as follows:
~~
We encourage CAs to technically constrain all subordinate
On 9/21/15 4:02 PM, Kathleen Wilson wrote:
The next item on our list to discuss is:
https://wiki.mozilla.org/CA:CertificatePolicyV2.3
(D2) CA/Browser Forum Baseline Requirements version 1.1.6 added a
requirement regarding technically constraining subordinate CA
certificates, so item #9 of the I
On 9/21/15 5:01 PM, Brian Smith wrote:
I think it is better to resolve whether email certificates and code signing
certificates are in or out of scope for Mozilla's policy first.
Good point. I will start the email trust bit discussion. We can figure
that out first.
Thanks,
Kathleen
On Mon, Sep 21, 2015 at 4:02 PM, Kathleen Wilson
wrote:
> Section 7.1.5 of version 1.3 of the Baseline Requirements says:
> The proposal is to simplify item #9 of the Inclusion Policy,
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> by referrin
appear within this extension.
- If the certificate includes the id-kp-serverAuth extended key usage,
then the certificate MUST include the Name Constraints X.509v3 extension
with constraints on both dNSName and iPAddress. For each dNSName in
permittedSubtrees, the issuing CA MUST confirm that the
Florian Weimer wrote:
> A PKIX-compliant implementation of Name Constraints is not effective
> in the browser PKI because these constraints are not applied to the
> Common Name.
>
> NSS used to be non-compliant (and deliberately so), so the constraints
> do work there, but I do
On 26/03/15 13:18, Peter Kurrasch wrote:
> So, how much work does Mozilla feel like doing?
You know my views; other Mozilla people will have to speak for
themselves. And then we'll have an argument to see whose view prevails
:-) However, this dialogue was very useful in exploring some of the
ramif
is not to the CA itself but to
everyone else on the Internet--regular, everyday users. When a CA system
becomes compromised, the bad actor will say: "Cool! Now, how much damage can I
inflict?" We should have a way to impose boundaries that intend to limit that
damage.
My whole viewpoint re
On 26/03/15 03:59, Peter Kurrasch wrote:
> Perhaps I chose my words poorly because my intention actually was to
> avoid having to pass judgment at all. Instead of saying to a CA "we
> don't trust you enough, please constrain" I was hoping for something
> along the lines of "everybody is asked to co
ually be quite an accomplishment if we could get every CA
to just agree to that much.
Original Message
From: Gervase Markham
Sent: Wednesday, March 25, 2015 6:54 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Name Constraints
On 24/03/15 21:12, Peter Kurrasch wrote:
> A
On 24/03/15 21:12, Peter Kurrasch wrote:
> As to who should be forced to constrain, this is controversial. I would
> argue that everyone should be forced, but that has certain problems. One
> can argue that only government-run and certain other CA's should be
> forced but then we are put in the pos
Looping back in the mail list which was dropped by mistake The issues at hand are: Who will choose to self-constrain? Who should be forced to constrain? Who benef
On 24/03/15 12:40, Peter Kurrasch wrote:
> I'm confused because it sounds like you're advocating for the status
> quo but I didn't think that was your position?
I am not in favour of non-consensual name constraints for CAs in
general. I think it would either be ineffective
org
Subject: Re: Name Constraints
On 24/03/15 05:01, Peter Kurrasch wrote:
> 1) As a first step on the path to fairness, perhaps there can be
> agreement that the goal of any name constraint policy should be the idea
> that a single root does not "get the whole internet". Maybe a wh
ght, but a single root should not. Could everyone agree?
I don't agree on that, because I don't yet think that a forced name
constraints policy for all CAs is a good idea at all.
Your proposal might reduce the risk to some degree, but not much. If I
broke into Foo CA's issuing system,
Hi Gerv,Obviously you are correct, it wouldn't make much sense to say "please constrain yourself to everything...or almost everything!"I think the only way for my alternative to work is to just develop a system of increased scrutiny of the intermediates, to develop a more rigorous set of policy agr
On 12/03/15 22:54, Peter Kurrasch wrote:
> This backwards compatibility problem is a fatal flaw, but I have an
> alternative in mind: establish and enforce boundaries within the
> intermediates. The browser can enforce a policy that a technical
> constraint be specified somewhere between the root a
* Richard Barnes:
> I've been doing some research on the potential benefits of adding name
> constraints into the Mozilla root program. I've drafted an initial
> proposal and put it on a wiki page:
>
> https://wiki.mozilla.org/CA:NameConstraints
>
> Questions an
I think some good work has been done here but the proposed solution is the wrong way to go since it establishes boundaries for CA's that are "locked in" at the browser, either in the form of a special table or in the trusted root store itself. While a method is provided for making changes to the b
On Tue, March 10, 2015 11:33 am, Gervase Markham wrote:
> The idea of forcibly constraining government CAs to issue for their own
> TLDs is, to me, a lot more plausible. For one thing, many government CAs
> don't have the same audits that non-governmental CAs do.
>
> The difficulty here is defi
ut creating
some "unconstrained" CAs, at which point we've just handed over a
market oligopoly. How do we decide who gets that?
* It's not possible for it both to be true that "The name constraints
for a root should allow issuance for any name that the CA wishes to
issue for&quo
don't think anyone opposes CAs requesting voluntary name constraints.
:-) The proposal here is that we impose them on CAs without their consent.
> This is a great point, and suggests that name constraint updates
> should either a) have a clear and defined update path, or b) only be
&
On Tue, March 10, 2015 1:11 am, Martin Rublik wrote:
> On 9. 3. 2015 18:11, Ryan Sleevi wrote:
> > Since Ballot 125 in the CA/Browser Forum (
> > https://cabforum.org/2014/10/14/ballot-125-caa-records/ ) CAs are
> > required
> > to disclose how they use/process CAA records.
>
> Does somebody know
On 9. 3. 2015 18:11, Ryan Sleevi wrote:
> Since Ballot 125 in the CA/Browser Forum (
> https://cabforum.org/2014/10/14/ballot-125-caa-records/ ) CAs are required
> to disclose how they use/process CAA records.
Does somebody know how many CAs actualy use CAA records?
Kind regards
Martin
On Mon, Mar 9, 2015 at 11:38 AM, Michael Ströder
wrote:
> Ryan Sleevi wrote:
> > Given that sites in consideration already have multiple existing ways to
> > mitigate these threats (among them, Certificate Transparency, Public Key
> > Pinning, and CAA),
>
> Any clients which already make use of C
On Mon, March 9, 2015 8:38 am, Michael Ströder wrote:
> Any clients which already make use of CAA RRs in DNS?
>
> Or did you mean something else with the acronym CAA?
>
> Ciao, Michael.
CAA (RFC 6844) is not for clients. It's for CAs, as another way of
restricting CAs authorized to issue for a
Ryan Sleevi wrote:
> Given that sites in consideration already have multiple existing ways to
> mitigate these threats (among them, Certificate Transparency, Public Key
> Pinning, and CAA),
Any clients which already make use of CAA RRs in DNS?
Or did you mean something else with the acronym CAA?
o be in anyone's real interests.
> I do not believe that the definition of secure origins is sustainable
> over the course of this century without the ability to extend the
> roots of that trust more widely in a safe way. It's not about
> governments -- they're just the en
easons
that a CA constrained to these domains could require less burdensome
auditing practices and agree to take on more liability for those
domains. It's up to each individual domain to choose to use that CA,
because this proposal is not intending to restrict which CAs a domain
can use.
Dec
and reason to have strong security as the holders
of a .com domain. This idea that somehow we can be less stringent with a
.ccTLD-constrained CA is downright dangerous, because it suggests now a
balkanization of web security as a desirable outcome.
> By contrast, name constraints protect *everyo
On Fri, Mar 6, 2015 at 8:39 PM, Ryan Sleevi
wrote:
>
> On Fri, March 6, 2015 4:26 pm, Richard Barnes wrote:
> > Hey all,
> >
> > I've been doing some research on the potential benefits of adding name
> > constraints into the Mozilla root program. I've
icert@lists.mozilla.org]
On Behalf Of Ryan Sleevi
Sent: Friday, March 6, 2015 6:40 PM
To: Richard Barnes
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Name Constraints
On Fri, March 6, 2015 4:26 pm, Richard Barnes wrote:
> Hey all,
>
> I've been doing s
On Fri, March 6, 2015 4:26 pm, Richard Barnes wrote:
> Hey all,
>
> I've been doing some research on the potential benefits of adding name
> constraints into the Mozilla root program. I've drafted an initial
> proposal and put it on a wiki page:
>
Hey all,
I've been doing some research on the potential benefits of adding name
constraints into the Mozilla root program. I've drafted an initial
proposal and put it on a wiki page:
https://wiki.mozilla.org/CA:NameConstraints
Questions and comments are very welcome. There's a
56 matches
Mail list logo
