First off, I would like to remind everyone that participation in this forum
is subject to Mozilla's Community Participation Guidelines [1].
The arguments that have been made for adding an exception to our policy for
Policy CAs have not, in my opinion, made a clear and compelling case for
the exception. The only CA that has argued for this exception is the one
that proposed it. On the other hand, I do still believe that adding this
exception creates a significant new risk by introducing a poorly defined
term ("Policy CA") and by making enforcement more difficult. Unless
additional information is presented here, I do not plan to implement this
proposal.
- Wayne
[1] https://www.mozilla.org/en-US/about/governance/policies/participation/
On Thu, May 9, 2019 at 9:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/05/2019 05:25, Ryan Sleevi wrote:
> > On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 09/05/2019 16:35, Ryan Sleevi wrote:
> >>> Given that the remark is that such a desire is common, perhaps you can
> >>> provide some external references documenting how one might go about
> >>> configuring such a set-up, particularly in the context of TLS trust?
> >>> Similarly, I'm not aware of any system that supports binding S/MIME
> >>> identities to a particularly CA (effectively, CA pinning) - perhaps you
> >> can
> >>> provide documentation and reference for systems that perform this?
> >>>
> >>> Thanks for helping me understand how this 'common' scenario is actually
> >>> implemented, especially given that the underlying codebases do not
> >> support
> >>> such distinctions.
> >>>
> >>
> >> My description is based on readily available information from the
> >> following sources, that you should also have access to:
> >>
> >
> > It looks like your links to external references may have gotten stripped,
> > as I didn't happen to receive any.
> >
> > As it relates to the topic at hand, the system you described is simply
> that
> > of internal CAs, and does not demonstrate a need to use publicly trusted
> > CAs. Further, going back to your previous message, to which I was
> replying
> > to make sure I did not misunderstand, given that you stated it was
> common,
> > it seemed we established that such scenarios in that message, and further
> > expanded upon in this, already have the capability for enterprise
> > management.
> >
> > I wanted to make sure I did my best to understand, so that we can have
> > productive engagement on substance, specifically around whether there is
> a
> > technical necessity for the use of non-Root CAs to be capable of issuance
> > under multiple different trust purposes. It does not seem as if there's
> > been any external references to establish a technical necessity, so it
> does
> > not seem like the policy needs to be modified, based on the available
> > evidence.
> >
>
> There were no links, only descriptions of obvious facts that you
> willfully ignore in an effort to troll the community.
>
>
> 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
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
