I think blank sections should be disallowed. The entire purpose of "No
stipulation" is to make it clear that the omission of content was intentional.
With regards to some of these sections being useful, I agree that a good CPS
contains more than the minimum content required from the BRs. I
That may be true, but I don't see any upside for using that date. If you need
to make a minor CPS update in early January for any reason, you now have
additional work.
I think late December policy changes should be avoided as a general rule.
-Tim
> -Original Message-
> From:
I agree with you, but December 31 is a particularly horrible compliance
deadline. Perhaps January 31?
-Tim
> -Original Message-
> From: dev-security-policy On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Monday, October 22, 2018 6:00 PM
> To: Kathleen Wilson
> Cc:
I'm glad you added the smiley, because in my experience CAs have rarely, if
ever, have had any discretion in such matters. Nor do we (DigiCert)
particularly want to, to be honest. I prefer clear, open, and transparent
validation rules that other CAs can't play games with.
Whitelisting and
Perhaps a simple first step is to mandate disclosure of which information
source was used for validation. Then if someone uses Google Maps or
similar, People Who Pay Attention To Such Things can start a public
discussion about whether the source is a QIIS, and whether the certificate
is
Getting the whitelist figured out and workable will take a while. Disclosure
could happen much faster.
And I’m curious why you think it would be unauditable. It seems
pretty straightforward to verify such disclosures.
It think both ideas are worth considering. There’s no reason we
RFC 3647 disagrees:
"Rather, a particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure."
" It is recommended that each and every component and subcomponent be
included in a CP
There have been previous discussions about this very issue at CA/Browser
Forum Validation Working Group meetings (see also draft Ballot 225). I
think it is widely recognized that the rules around QIISs are far too weak
and in need of improvement.
I actually recently asked Kirk to add an item on
Here's the article we published on this subject a while ago:
https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practices/
-Tim
> -Original Message-
> From: dev-security-policy
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, January 10, 2019 4:47
I don't think we've commented on this before, but I'll note that sending an
e-mail
from the e-mail address listed as the contact address on a website is not
one of
the approved methods of showing ownership or control of a website as
specified
in section 3.2.2.4. The approved methods of validating
The problem is that the attackers get to choose the CA they use, so
multi-perspective validation doesn't provide any benefits unless everyone
has to do it.
I brought it up several times at the validation working group and as a
discussion topic at the Shanghai face to face, but unfortunately there
I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the Baseline Requirements. It's also deprecated.
> On 27/02/2019 00:10, Matthew Hardeman wrote:
> > Is it even proper to have a SAN dnsName in in-addr.arpa ever?
> >
> > While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it
> > rarely has anything other than PTR and NS records defined.
> >
>
> While there is no current use, and the
What is the rationale for waiting until March 20th for revocation given that
the issue was noticed on March 7th?
-Tim
> -Original Message-
> From: dev-security-policy
On
> Behalf Of Bruce via dev-security-policy
> Sent: Friday, March 15, 2019 4:59 PM
> To:
> On 2019-01-24 20:19, Tim Hollebeek wrote:
> > I think the assertion that the commonName has anything to do with what
> > the user would type and expect to see is unsupported by any of the
> > relevant standards, and as Rob noted, having it be different from the
> > SAN strings is not in
DigiCert currently has a policy of not publishing the names of those who
report things to us without their permission. It just seems like the right
thing to do.
If we do find that people are abusing that protection to selectively harass
people that they personally have issues with, we may need
So, pinning is an extremely complicated topic that I've always wanted to write
a blog post about, but have never had the time to do it. It happens fairly
regularly that we have to assist a company that has painted themselves into a
corner with a poorly thought out pinning scheme.
In my
So, this is something that would be helpfully clarified via either an IETF
draft, or clarifications in the BRs. There are various things in the OCSP RFCs
and even the BRs that can be read as precluding good OCSP responses for
pre-certificates, although the situation is unclear since the
r
>
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > So, this is something that would be helpfully clarified via either an
> > IETF draft,
>
> There's already a 6962-bis draft [1] in I
On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
So, this is something that would be helpfully clarified via either an IETF
draft, or clarifications in the BRs. There are various things in the OCSP RFCs
t; >> Sent: Friday, September 13, 2019 4:22 AM
> >> To: Tim Hollebeek ; Jeremy Rowley
> >> ; Alex Cohn
> >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >>
> >> Subject: Re: DigiCert OCSP services returns 1 byte
> >>
> Thanks Wayne. You're right.
>
> (I read the "SHOULD NOT" requirement, forgot it had been superseded, and
> didn't read further. I wonder if it would be reasonable to remove the
> superseded requirement from the BRs now, given that it was superseded over
> 6 years ago?)
Removing out of date
Subject: Re: DigiCert OCSP services returns 1 byte
On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
I think that's fine as Mozilla and/or the CABF can and should override RFCs
when it makes sense to
Someone really should write up "AIA chasing considered harmful". It was
disputed at the TLS session at IETF 105, which shows that the reasoning
behind it is not as widely understood as it needs to be, even among TLS
experts.
I'm very appreciative of Firefox's efforts in this area. Leveraging
Generally, I'm in favor of transparency requirements, and many of Ryan's ideas
would be useful or interesting to pursue. Transparency is often the first and
best
step towards improving business practices. And the entire purpose of a CPS is
to
disclose the business practices that implement a
I agree with Corey on this. I was disappointed that the LAMPS discussion two
years ago was not as helpful as it could have been.
For what it's worth, while we generally try to accept any reasonable proof of
key
compromise, we have seen quite a large variety of things sent to us. This
includes
> On 3/11/20 3:51 PM, Paul Walsh wrote:
> > Can you provide some insight to why you think a shorter frequency in
> domain validation would be beneficial?
>
> To start with, it is common for a domain name to be purchased for one year.
> A certificate owner that was able to prove ownership/control
Hello,
I'd like to start a discussion about some practices among other commercial
CAs that have recently come to my attention, which I personally find
disturbing. While it's perfectly appropriate to have Terms and Conditions
associated with digital certificates, in some circumstances,
So, from our perspective, the security implications are the most important here.
We understand them, and even in the absence of any compliance obligations they
would constitute an unacceptable risk to trustworthiness of our OCSP responses,
so we have already begun the process of replacing the ICAs
Ben,
We're concerned that these changes could unintentionally prevent many new
auditors from being able to conduct audits, despite being Qualified Auditors.
The problem is that CAs will understandably be very hesitant to use a new
auditor, as they cannot risk having an audit conducted, and
So, I'd like to drill down a bit more into one of the cases you discussed.
Let's assume the following:
1. The CAO [*] may or may not have requested removal of the CAC, but removal
has not been completed. The CAC is still trusted by at least one public
root program.
2. The CAO has destroyed the
In the definition of EV TLS Capable, I'd move the last bullet up to the top.
This is because the definition is inherently recursive, and it's easy to
miss that
if the recursion rule isn't first.
For example, I had a question about whether "revoked" meant just the
certificate
itself, or whether
I know where this kind of requirement is coming from ... it's a common
requirement in key management systems, but they generally operate in worlds
that are completely different from the Web PKI. Even there, it often causes
more problems than it solves. I've spent more of my life dealing with the
101 - 133 of 133 matches
Mail list logo
