Was looking for some quick clarification on interpretation of this bit:
*"All certificates containing an underscore character in any dNSName entry
and having a validity period of more than 30 days MUST be revoked prior to
January 15, 2019."*
This language refers to the TOTAL validity period of
For posterity, here is a link to a separate thread started by D-Trust
containing their response to this report:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/UnR98QjWQQs
-Vincent
___
dev-security-policy mailing list
Jakob,
I don't see what is wrong with Jonathan reporting these issues. The authors
and ratifiers of the BRs made the choice to specify these small details.
While a minor encoding error is certainly not as alarming as say, issuing
an md5 signed certificate, it is still an error and is worth
Hi Gerv,
Thank you for reaching out to the mdsp community.
There are valid security reasons to consider a dis-trust date earlier than
April 2018 for the corpus of Symantec certs issued prior to June 1st, 2016.
However, I also believe there are security and operational risks in
complicating the
Hi Gerv,
I interpreted your wording as meaning that Symantec will be publicly posting a
new document (presumably to this list or blink-dev). Is this accurate?
If so, do you (or anyone else at Mozilla, since your vacation has now started)
know when Symantec plans on doing so?
-Vincent
On
Hi Inigo,
You mentioned there would be a report attached but I believe you forgot to
send it?
Can you upload the report and provide a URL? I believe that's the 'best
practice' for sharing files here as it allows non-subscribers to access the
file via the Google Groups archive.
-Vincent
On Thu,
Hi Yuhong,
Yes, there may not be much harm in a mis-issued certificate for example.com
due to its purpose/use.
However, from the perspective of root programs and the CA/B Forum, it is
still mis-issuance and considered a serious problem. CAs should not be
issuing certificates without documented
Hi Gervase,
Thank you for the update on Mozilla's process.
I have one question regarding your wording. You write"I am therefore *proposing
*the following," and then you list your changes.
Does this mean that the "alternative" option is officially, 100%, off the
table? Or is this still an option
>
> Finally, what have you actually done to address EV revocation? You clearly
> didn't bother to tell Commonwealth Bank:
>
> https://www.commbank.com.au/
>
> One of the largest banks in Australia that their EV status would evaporate
> in Chrome. So what did you do to inform your customers about
On Tuesday, March 28, 2017 at 11:08:08 PM UTC-4, uri...@gmail.com wrote:
> For what it's worth, this is the latest post on facebook from the researcher.
> https://www.facebook.com/cbyrneiv/posts/10155129935452436
>
> The private key storage issue sounds like a reseller tool, like
>
Hi David,
I am the author of the research discussed in that Bleeping Computer post..
Your post is a bit brief, so I'm not sure if you are just sharing news, or
wanted to discuss a certain aspect of this story or topic.
So I will just share some general thoughts:
1. The most important thing
As you have quoted it, Let's Encrpyt's CPS says:
"the CA is *entitled* to revoke the certificate"
The key word is "entitled." Meaning that Let's Encrypt may revoke the
certificate if they chose, but are not required to. Therefore not revoking
the certificate is compatible with their CPS.
It's
Hi Richard,
Peter's point is that there is no standard definition of a "high-risk"
request." It is a term defined in Section 1.6.1:
"High Risk Certificate Request: A Request that the CA flags for additional
scrutiny by reference to internal criteria and databases maintained by the
CA, which may
13 matches
Mail list logo
