Re: Do we need multiple name constraints on one certificate chain?

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

Re: Do we need multiple name constraints on one certificate chain?

g 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 EKU (server-auth) for "2nd intermediate cert"

Re: Do we need multiple name constraints on one certificate chain?

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

Re: Do we need multiple name constraints on one certificate chain?

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年

Re: Do we need multiple name constraints on one certificate chain?

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

Re: Do we need multiple name constraints on one certificate chain?

" 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? >

Do we need multiple name constraints on one certificate chain?

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

RE: SRVNames in name constraints

r...@sleevi.com>; Peter Bowen <p...@amzn.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: SRVNames in name constraints On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley <jeremy.row...@digicert.com> wrote: > I realize use of

Re: SRVNames in name constraints

Jeremy, I was assuming the 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 m

RE: SRVNames in name constraints

Of Peter Bowen via dev-security-policy Sent: Tuesday, August 15, 2017 8:51 AM To: Gervase Markham <g...@mozilla.org> Cc: Ryan Sleevi <r...@sleevi.com>; Peter Bowen <p...@amzn.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: SRVN

Re: SRVNames in name constraints

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"

Re: SRVNames in name constraints

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

Re: SRVNames in name constraints

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

Re: SRVNames in name constraints

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

Re: SRVNames in name constraints

are not technically constrained to 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: n

Re: SRVNames in name constraints

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

Re: SRVNames in name constraints

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

Re: SRVNames in name constraints

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

RE: SRVNames in name constraints

-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 Alternative Names

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 Names (SANs) of any of the following types: dNSName, iPAddress, SRVName, rfc822Name" SRVName is not yet allowed by the CA/Browser Foru

Re: Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

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

Re: Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

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

Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

NOT 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

Re: Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

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

Re: Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

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

Re: Name Constraints

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

Re: Name Constraints

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

Re: Name Constraints

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: As to who should be forced to constrain

Re: Name Constraints

: 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 whole CA organization might, but a single

Re: Name Constraints

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 in improving security

Re: Name Constraints

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, and Foo CA has two roots, one for one half

Re: Name Constraints

‎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

Re: Name Constraints

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

Re: Name Constraints

* 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 and comments are very welcome. A PKIX

Re: Name Constraints

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?

Re: Name Constraints

On Mon, Mar 9, 2015 at 11:38 AM, Michael Ströder mich...@stroeder.com 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

Re: Name Constraints

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

Re: Name Constraints

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: https://wiki.mozilla.org/CA:NameConstraints