e Requirements, section 7.1.
>
>
> Regards,
>
>
> --
>
> Scott Rea
>
> On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via
> dev-security-policy" of dev-security-policy@lists.mozilla.org> wrote:
>
> On Friday, Feb
n the identified
> intermediate certificates, is a violation??
>
> Regards,
>
>
> --
>
> Scott Rea
>
> On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via
> dev-security-policy" of dev-security-policy@lists.mozilla.org> wrote:
>
On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote:
> Hello,
> Section 7.1 of the Baseline Requirements states that, "Effective September
> 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers
> greater than zero (0) containing at least 64 bits of output from
Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet
by specifying a single iodef CAA record without any issue/issuewild records in
the RRSet, which will probably be treated as permission to issue for CAs. I say
“probably” because the RFC wasn’t clear on the proper
On Friday, March 15, 2019 at 9:26:02 PM UTC-4, Jan Schaumann wrote:
> Matt Palmer via dev-security-policy
> wrote:
>
> > I've read through your posts on this topic several times, and I still don't
> > understand the problem you're trying to solve. If you point a CNAME at
> > someone else,
Hello,
Section 5.1 of the Mozilla Root Store Policy
(https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
specifies the allowed set of key and signature algorithms for roots and
certificates that chain to roots in the Mozilla Root Store. Specifically, the
On Tuesday, February 12, 2019 at 3:15:09 PM UTC-5, Wayne Thayer wrote:
> Thanks Corey and Jakob, I opened a bug for this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1527423
>
> Corey, did you report this via DigiCert's problem reporting mechanism?
>
> Thanks,
>
> Wayne
>
> On Mon, Feb 11,
On Sunday, February 10, 2019 at 6:33:19 AM UTC-5, Ryan Sleevi wrote:
> On Sat, Feb 9, 2019 at 8:55 PM Corey Bonnell via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hello,
> > Section 5.1 of the Mozilla Root Store Policy (
> > ht
On Friday, June 14, 2019 at 1:31:12 PM UTC-4, kirkhal...@gmail.com wrote:
> CAs already have rules allowing a Parent, Subsidiary, or Affiliate (all
> defined terms) to obtain certs for domains owned by each other - so
> Alphabet-Google, for example, can get certs for domains owned by each other.
On Tuesday, June 11, 2019 at 7:49:31 AM UTC-4, Jeremy Rowley wrote:
> We wanted to experiment a bit with logotype extensions and trademarks, but
> we heard from the CAB Forum that whether inclusion is allowed is subject a
> bit to interpretation by the browsers.
>
>
>
> >From the BRs section
Hello,
Section 4 of Mozilla Root Store Policy states that CAs are bound by the latest
Common CCADB Policy (http://ccadb.org/policy). Section 5 of the Common CCADB
Policy specifies the requirements for CAs regarding providing URLs to various
documents, such as the CP, CPS, and audit reports. In
On Thursday, July 18, 2019 at 3:42:00 PM UTC-4, Matthew Hardeman wrote:
> Regarding indicators, I agree that it should be more apparent. Perhaps a
> dedicated bar that occupies an entire edge-to-edge horizontal area.
>
> I would propose that it might have two distinct messages, as well:
>
> 1.
ty-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote:
> > > (Posting in a personal capacity as I am no longer employed by Trustwave)
> > >
> > > Mozilla Root Store
On Monday, October 7, 2019 at 10:52:36 AM UTC-4, Ryan Sleevi wrote:
> I'm curious how folks feel about the following practice:
>
> Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They
> create this Root Certificate after the effective date of the Baseline
> Requirements, but
g this idea, but ISTM that you've stopped slightly short of
actually proposing it in this list thread.
@Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI is
kinda stuck with it now (see RFC8555).
_____
From: dev-security-policy mailto:dev-security-polic
There was quite a bit of discussion on the development of a standard
revocation request format on LAMPS WG mailing list two years ago in the wake
of the Trustico mass revocation:
https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-Q_47QKNdyOOxsAT3Zk/.
Nothing was developed in terms of a
@Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI is
kinda stuck with it now (see RFC8555).
_
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > on behalf of Corey
Bonnell via dev-security-policy mailto:dev-secu
On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote:
> I've made some additional improvements to the survey based on feedback from
> Kathleen:
>
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW
>
> I'm
On Monday, March 9, 2020 at 2:48:56 PM UTC-4, Kathleen Wilson wrote:
> * The root contains subject L and organizationIdentifier fields which
> are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the
> subCAs also exhibit this issue.
Given that Mozilla explicitly encourages CAs to
> As owner of the certificate, I think you actually don't want to do that,
> because things will stop working. If it's revoked you want to get a new
> certificate, and as long as you don't have the new one, you want to use the
> old certificate and staple the good OCSP response.
>
That depends on
Hi Kathleen,
Thank you very much for the clarifications. If I'm understanding correctly, it
sounds like Mozilla is considering to add sub-items of item 4 on the survey as
Mozilla Root Program requirements if the associated CAB Forum ballot does not
pass. However, there is concern that many CAs
> * Are there rules that CAs must adhere to in regards to referencing the
> intermediate in the AIA field? Does it need to be available? Does it
> need to be there at all?
It's optional (SHOULD-level), as Baseline Requirements 7.1.2.3 (c) [1] states:
It (AIA extension) SHOULD also
While I realize the current topic is concerning TLS, I find it rather
surprising that Mozilla Policy does not mandate PoP for S/MIME certificate
issuance. Lack of checking for S/MIME would present more concrete security
concerns, so perhaps this should be addressed in a future update to the
> Not Kathleen here, but it seems to make sense to me, for the same reason
> Item 3 makes sense. That is, in Item 3, Apple's deployed a policy, and
> there's
> a question about if/when Mozilla should do the same. Item 4 seems similar -
> 4.1 is a Microsoft requirement, 4.2 is an existing Mozilla
Hi Kathleen,
Thank you for sending out this notification of the draft survey. I have briefly
reviewed and would like to ask what is the intent of Item 4 and the associated
sub-items? The Browser Alignment draft ballot is under discussion in the CAB
Forum, so the intent behind the shift of the
I did some searching in this area after Microsoft announced the new root
program requirement back in February [1] and it appears that v1 CRLs are still
being actively published in the webPKI. Notably, v1 CRLs do not support
extensions in revoked entries, so there is no way to encode the
(Sorry Ryan and Neil for the double-email, I accidentally omitted the list on
the first email)
> As others have rightfully pointed out, if the EKU is present, it is a
> delegated responder, full stop.
For the certificate to be used as a delegated responder (as opposed to an
issuer of OCSP
> No, this isn’t specified/required for Delegated Reaponders (at least, by
> 6960), and the client implementations I looked at did not check.
>From RFC 5280, section 4.2.1.12:
If a certificate contains both a key usage extension and an extended
key usage extension, then both extensions
> Policy-wise, apparently it's OK for a certificate to be both a CA
> certificate and
> a (correctly issued!) delegated OCSP signing certificate, which is I think
> what
> Ryan's earlier post was talking about. So if the affected CAs could go back
> in
> time and add the id-pkix-ocsp-nocheck
>> If a certificate contains both a key usage extension and an extended
key usage extension, then both extensions MUST be processed
independently and the certificate MUST only be used for a purpose
consistent with both extensions.
> You're reading an obligation on the CA, not an
> I don’t understand why you’re making a distinction as to CA certificates,
which are irrelevant with respect to the Delegated Responder profile. That
is, you’re trying to find a way that it’s compliant, but this introduction
of the CA bit as somehow special doesn’t have any basis, as far as I can
>> It’s an obligation on the client, because the verb “processed” makes no
sense if the intent were to restrict only CAs.
> They're processed independently. The usage requirement is on the CA.
I don't see how this is relevant. The language clearly states that clients must
process both the KU
Hi Kathleen,
Thank you for posting the notification concerning the update to CCADB. I have a
follow-up question: in the discussion captured in
https://github.com/mozilla/pkipolicy/issues/218, it appears that there's a
desire for CAs to produce and publish complete CRLs for end-entity
Thanks for the additional context, Ben. Given the comment that you linked to,
it appears that there’s a possibility that Mozilla will support sharded CRLs
and that there may be logic included in the CRLLite crawler to timeout and
remove the issuing CA from the crawler configuration if
As an alternate proposal, I suggest replacing the third paragraph of section
5.3, which currently reads:
"These requirements include all cross-certificates which chain to a certificate
that is included in Mozilla’s CA Certificate Program."
with:
"A certificate is considered to directly or
I reviewed the associated GitHub commentary on the following change:
"Full-surveillance period-of-time audits MUST be conducted and updated audit
information provided no less frequently than **annually** until the CA
certificate is no longer trusted by Mozilla's root store. Successive audits
Hi Ben,
A few follow-up questions and comments:
1) What are the expectations regarding availability for such CRLs? Do the
availability requirements in BR 4.10.2 stand for these CRLs even if such CRL
pointers are not encoded in end-entity certificates?
2) What is the expectation for populating
My understanding is that neither the BRs or any Root Program require that that
subordinate CA key be weaker or equal in strength to the issuing CA's key.
Additionally, such a requirement would prohibit cross-signs where a "legacy"
root with a smaller key size would certify a new root CA with a
38 matches
Mail list logo
