On 10/10/16 16:47, 谭晓生 wrote:
> Yes, the certificate issuance process is performed by each of these
> five components, except, TSA is used for code issuance and PDF
> issuance, not related with SSL certificates issuance.
Right :-) But can you explain what each component does specifically? E.g.:
1
On 10/10/16 23:00, Ryan Hurst wrote:
> I also believe there are a few core questions that are relevant to
> “what it depends on”, these include: Is it reasonable for the
> operational and technical failures StartCom made prior to the
> acquisition to be handled as a separate incident?
I presume y
On 11/10/16 01:04, Kathleen Wilson wrote:
> I think what you are saying is that the CA needs to re-apply for
> inclusion with new root certificates (not their old root certs).
> Correct? If yes, I am inclined towards that idea too. I've heard that
> it would cause continuity issues, but I don't get
On 11/10/16 02:55, Ryan Sleevi wrote:
> CAs would and could address that continuinity by signing their new
> root with their old (distrusted) root, and only issuing certificates
> with the new root, while the old root fades into obsolecence.
>
> This offers continuity because the certs issued by n
Hi Eddy,
While I have sympathy with what you say, your analysis is incomplete in
one respect.
On 11/10/16 09:41, Eddy Nigg wrote:
> The problematic issue in relation to StartCom is obviously the _two
> backdated SHA1 certificates_
There is also the case of StartEncrypt. While no known
cert-to-w
On 11/10/16 15:08, Nick Lamb wrote:
> Mozilla could choose to do that too, and agree that when a new CA is
> added to NSS it will use the Mozilla CA (trusted but never used to
> issue end entity certificates) to cross sign the new CA. The
> resulting certificate could be included in chains for the
On 12/10/16 14:46, Konstantinos Tsimaris wrote:
> I have seen various posts mentioning that after 1 of January 2017, browsers
> will stop support of SHA1 signed CAs. I am looking into a way to identify
> which WEB sites will not work until new certificate is applied and
> demonstrate that after cha
On 13/10/16 01:40, Percy wrote:
> (Hmm, my previous comment about two faced WoSign disappeared from
> Google group probably due to anti-spam. Gerv, can you recover it for
> me?)
I have that message via the news interface, so it did get posted. It's
not in the spam filter.
Gerv
___
A note on accepted content for this list:
Concrete information which may be important for security policy
decisions Mozilla has to make is welcome. Wild and unsubstantiated
accusations are not, nor are comments which attack a person or company
based on their nationality. I have already rejected on
On 13/10/16 17:49, Kathleen Wilson wrote:
> Thanks again to all of you who have put in so much time and effort to
> determine what happened with WoSign and StartCom and discuss what to
> do about it.
You are welcome.
As people will have read, the current decision at Mozilla is to treat
the WoSign
On 14/10/16 02:20, Matt Palmer wrote:
> Will there be any requirements around the qualification status of the logs,
> or could anyone who wanted to be "nice" just stand up a log, and have these
> CAs obtain precerts from them?
Log qualification is a Chrome concept - it means "suitable for being
tr
On 14/10/16 10:41, Rob Stradling wrote:
> Gerv, does Mozilla need to make a final decision on this point immediately?
>
> I very much hope that there will be more CT logs by the time StartCom
> and/or WoSign are readmitted into Mozilla's trust list. Why not delay
> making this decision until near
On 13/10/16 23:42, Nick Lamb wrote:
> Please can Mozilla ensure that both EY Hong Kong and the overarching
> parent organisation in the United Kingdom (in Southwark) are informed
> of this ban and get a copy of Mozilla's findings if they haven't
> already ?
This is a good idea; I will try and figu
On 12/10/16 20:11, Ryan Sleevi wrote:
> As Gerv suggested this was the official call for incidents with
> respect to StartCom, it seems appropriate to start a new thread.
There are indeed more of these than I remember or knew about. Perhaps it
would have been sensible to start a StartCom issues li
On 14/10/16 11:37, Rob Stradling wrote:
> Sure, but aren't we talking about specifying criteria for which log(s)
> StartCom/WoSign _can't_ use in future?
>
> If Mozilla would prefer to forbid StartCom/WoSign from using their own
> or each other's logs, then ISTM that it would be best to specify
>
On 14/10/16 15:46, Gervase Markham wrote:
> I think the rule we are putting in place is that: "StartCom/WoSign
> SHOULD NOT fulfil the non-Google log requirement by using logs that they
> run themselves. For as long as they do so, they will need to demonstrate
> ongoing evidence
Hi Inigo,
On 14/10/16 09:16, Inigo Barreira wrote:
> In this link,
> https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf,
> you´ll find the detailed remediation plan for StartCom as was notified last
> week.
Thanks for this. Is this a correct summary of the situation as regard
Hi Xiaosheng,
On 14/10/16 16:06, 谭晓生 wrote:
> We’ll rewrite all the code with different programing language or buy
> 3rd party components (for example: PKI), Wosign team using .Net, but
> my team never use .Net, they are good at C/C++ and PHP, Python.
It would be great to be clear about what the
On 15/10/16 00:32, Peter Gutmann wrote:
> I would have expected some sort of coordinating action to provide a unified
> response to the issue and corresponding unified, consistent behaviour among
> the browsers, rather than the current lottery as to what a particular browser
> (other than Apple and
On 16/10/16 08:59, Adrian R. wrote:
> is this revival/un-revocation of an intermediary CA allowed by the
> BRs?
I agree that the wording is a little loose but I think the intended
purpose of the clause in question was as Peter interprets it - don't
remove things from OCSP or CRLs before their expi
On 17/10/16 16:08, Jakob Bohm wrote:
> 5) OneCRL, even if it was checked by other projects, is an arbitrary
> hodgepodge of CA revocations, SubCA revocations and selected end-cert
> revocations, that cannot possibly match the policies of anyone except
> its maintainers.
Once fully deployed (
On 17/10/16 16:35, Jakob Bohm wrote:
> In the not so distant past, the Mozilla root program was much more
> useful due to different behavior:
>
> 1. Mozilla managed the root program based on an assumption that relying
> parties would use the common standard revocation checking methods
> *only*
Hi Ryan,
Kathleen has responded, but here are my two cents:
On 14/10/16 13:21, Ryan Sleevi wrote:
> It seems to accomplish this, you're willing to continue to trust that
> WoSign will not demonstrate any of the past behaviours it already
> demonstrated - such as backdating and misissuance, but no
On 17/10/16 16:26, Kathleen Wilson wrote:
> ones who use NSS validation. I’m not sure what we can do about other
> consumers of the NSS root store, other than publish what we are doing
> and hope those folks read the news and update their version of their
> root store as they see appropriate for th
On 18/10/16 01:00, Nick Lamb wrote:
> As I understand it QiHoo 360 says they intend to co-operate in order
> to eventually get the new StartCom CA trusted. If they are unwilling
> to communicate with existing subscribers of both existing CAs
> effectively, it seems to me this is evidence of bad fai
On 18/10/16 06:00, Jakob Bohm wrote:
> Non-https TLS is not (and should not be) a separate trust bit from
> https, but sometimes the logic applicable to trust policies, BRs etc.
> will be slightly different if one doesn't ignore non-https use of TLS.
> I have encountered arguments and policies that
On 18/10/16 07:17, Kurt Roeckx wrote:
> On 2016-10-18 14:51, Gervase Markham wrote:
>>
>> The audit report CNNIC has submitted covers the period from November 2,
>> 2015 to February 29, 2016. Therefore, we would expect them to be
>> starting the process of getting anot
Hi Inigo,
On 18/10/16 07:34, Inigo Barreira wrote:
> So, regarding the situation of StartCom I think that some people has
> lost what happened and it´s considering Wosign and Startcom the same.
Kathleen may also respond, but my understanding is that (based on her
consideration of the arguments pu
On 18/10/16 09:03, Kurt Roeckx wrote:
> You said the period was until February 29, 2016. I assume the next
> period starts on March 1, 2016 and is for 1 year. I don't expect it to
> from from March to November, it would be an 8 month period.
Surely if audits last one year, one would be auditing th
Hi Peter,
On 18/10/16 06:02, Peter Bowen wrote:
> I think making it clear which entries in certdata.txt have additional
> constraints would be very helpful. Is it maybe possible to do so by
> adding new attributes to the NSS_TRUST object instead of simply
> putting it on a webpage? That way it i
On 18/10/16 06:02, Peter Bowen wrote:
> I think making it clear which entries in certdata.txt have additional
> constraints would be very helpful.
Here's a start:
https://wiki.mozilla.org/CA:Root_Store_Trust_Mods
I believe the ANSSI root has now been removed and so CNNIC is the only
one (leaving
On 18/10/16 12:46, Kurt Roeckx wrote:
> Are you saying you're expecting an audit report from November 2015
> to November 2016, and so have the period from November to March
> covered twice?
There seems to be a persistent misunderstanding here.
https://cert.webtrust.org/SealFile?seal=2092&file=pdf
Just a reminder: people participating here more than occasionally are
encouraged to add themselves to:
https://wiki.mozilla.org/CA:Policy_Participants
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.o
On 18/10/16 14:33, Ryan Sleevi wrote:
> I think there's some confusion there. CNNIC's audits "expire" on Feb
> "29" 2017 (I say "29" because of ambiguity on "1 year"). That is,
> within 3 months of Feb "29", 2017, CNNIC would be expected to provide
> a new audit, which covers February 29, 2016 (the
On 18/10/16 15:42, Ryan Hurst wrote:
> I do not understand the desire to require StartCom / WoSign to not
> utilize their own logs as part of the associated quorum policy.
My original logic was that it could be seen that the log owner is
trustworthy. However, you are right that CT does not require
On 18/10/16 16:04, Han Yuwei wrote:
> For the CT support, is there any plan to implement it into effect in
> Firefox? And if implemented, what would happen if server's
> certificate don't have enough SCTs?
The mechanism is being implemented. When it's closer to being
implemented, there will be a d
On 19/10/16 11:35, longol...@gmail.com wrote:
> Hey Kathleen, hey list,
>
> I really don't get why Mozilla is pushing so hard on the Chinese and
> at the same time let others get away. For example the Comodo case
> from today. Isn't that a much worse incident than what has happened
> here.
Today
On 19/10/16 15:13, okaphone.elektron...@gmail.com wrote:
> Perhaps "haste" is not what you want here. How about "urgency"?
I was using it in the sense of the English phrase "more haste, less speed":
http://dictionary.cambridge.org/dictionary/english/more-haste-less-speed
But yes, urgency is fine.
On 20/10/16 15:05, Kathleen Wilson wrote:
> You are receiving this email because our records indicate that there
> are non-technically-constrained intermediate certificates that chain
> up to your root certificates that are included in Mozilla’s program
> that have not been entered into the CA Comm
On 20/10/16 13:09, Kathleen Wilson wrote:
> Next week I expect to have a better capability for sending
> notification emails to CAs. The first email I would like to try this
> new tool on is regarding the CAs who have not disclosed all of their
> non-technically-constrained intermediate certificate
In a development which proves that irony is not dead, I need to request
participants in this forum to avoid S/MIME-signing their messages here
until further notice. It appears that under some circumstances (the
exact ones are unclear), Google Groups is failing to archive such messages.
Such messag
On 21/10/16 17:21, Eric Mill wrote:
> Can you confirm whether this affects people who subscribed through Google
> Groups but participate via email, or whether it only impacts users who read
> the list through the Google Groups web interface?
The lack-of-message affects everyone who views the Googl
On 22/10/16 20:41, Peter Bowen wrote:
> According to the wiki, Asseco Certum has cross-signed at least one of
> these roots. Is it expected that Certum will take any action, or do
> the above changes mean that Certum's cross-sign of WoSign will be
> considered to not exist for the purpose of Mozil
On 24/10/16 06:55, Samuel Pinder wrote:
> There's some good questions there, actually. OEM SSL, does that mean
> another CA would be doing the validation and issuing using their own
> infrastructure and team, which you would be reselling via a
> constrained intermediate?
I suspect he means tha
On 24/10/16 09:33, Mathias Tausig wrote:
> Really only S/MIME signaures, or should PGP signatures be avoided, too?
I'm not aware of the problem occurring with PGP signatures, but feel
free to test in mozilla.test.
Gerv
___
dev-security-policy mailing l
On 26/10/16 02:30, Ryan Sleevi wrote:
> So we certainly know that Mozilla's policies are, in some ways,
> designed to minimize the number of errors that users are presented
> with, by allowing a gradual fade out of insecure or undesirable
> practices. A change in the BRs is, in theory, supposed to
On 26/10/16 22:02, Kathleen Wilson wrote:
> I agree that I should add a section about that to
> https://wiki.mozilla.org/CA:SalesforceCommunity I don't agree that it
> needs to be resolved before reminding these particular CAs about
> their overdue action items. If they fall into that category, th
On 26/10/16 18:53, Ryan Sleevi wrote:
> interpretation of #2. This is also why I support the mandatory
> disclosure of TCSCs to Mozilla Salesforce, to ensure that the
> Technical Constraints are properly implemented and conforming in
> order for the CA to claim its exclusion.
If we were to require
On 27/10/16 23:43, Han Yuwei wrote:
> Since Mozilla's working language is English (Not sure about this),
That is true.
> it's your responsibility to provide an accurate translation of CPS.
That is also true. However, we don't require that the English version be
the master copy.
Gerv
___
On 28/10/16 16:11, Patrick Figel wrote:
> #7
> Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA"
> (Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth
> certificates, but I don't think the intermediates have any relevant
> technical constraints. I'm not sure
On 28/10/16 16:11, Patrick Figel wrote:
> I found a number of SHA-1 certificates chaining up to CAs trusted by
> Mozilla that have not been brought up on this list or on Bugzilla yet.
> Apologies in case I missed prior discussion for any of these, and kudos
> to censys for making this search incred
On 29/10/16 22:23, Han Yuwei wrote:
> Is SM2 acceptable in publicy-trusted CAs? I don't think so.
No; the BRs list the permitted algorithms, and SM2 is not one of them.
> Maybe Gerv could explain more about this. And I am wondering what can
> CA do if government requirement conflicts with Mozilla
On 29/10/16 22:42, Percy wrote:
> However, on the official website
> (https://www.wosign.com/about/Why_WoSign.htm) WoSign stated that "沃通是
> 中国唯一一家也是全球唯一一家能签发全球信任的采用国产加密算法(SM2) 的SSL证书和代码签名证书的商业CA。" WoSign is
> the only commercial CA in China -- only commercial CA in the world
> that can Sign SM2 SS
On 30/10/16 12:39, 谭晓生 wrote:
> That’s the dilemma we have:
> Block the access to self-issued certificates, user will ignore and force
> trust the certificated, bad behavior training, user might change to
> competitor’s product.
> Do not block the access, there are possibility to do the MITM atta
On 30/10/16 19:47, Han Yuwei wrote:
> SM2 is widely used in Chinese government websites. There is a openssl
> branch (https://github.com/guanzhi/GmSSL) who implemented
> SM2/SM3/SM4. And I don't see any other depolyment in HTTPS.
Right, but my question remains: can you find a site with a WoSign SM
On 31/10/16 18:25, Percy wrote:
> According to http://se.360.cn/event/gmzb.html, the browser needs to send a
> http header Accept-Protocal: SM-SSL.
That seems like an odd mechanism, because SSL connection establishment
happens before HTTP header transmission. Does this header mean "Next
time you
On 31/10/16 06:30, chun.yin.che...@cn.pwc.com wrote:
> Help. My previous email account (cheungchun...@gmail.com) Is blocked. I
> want to subscribe to the mailgroup using my company account
> (chun.yin.che...@cn.pwc.com).
I don't know why you think it's blocked, but you can see details on how
t
Hi dracenmarx,
On 02/11/16 12:44, dracenm...@googlemail.com wrote:
> (1) I did find any public answer from Apple, Google or Mozilla in
> regards to the Remediation plan by StartCom. I have the feeling, that
> the sanctions were applied without considering this document. (
> https://www.startssl.co
Hi Daniel,
On 02/11/16 14:11, Itzhak Daniel wrote:
> Interesting that Comodo and DigiCert are getting a different
> treatment,
As far as the DigiCert certs go, it is far too early to have an opinion
on what Mozilla is or isn't doing. And let us remember, the WoSign
incident involved multiple ins
On 02/11/16 16:01, Nick Lamb wrote:
> Maybe this can to some extent be fixed, but there are many other ways
> in which DNS names now have a footprint that extends beyond the life
> of the domain registration. Cookies and HSTS rules, spam blocks,
> Google search karma, and so on. So arguably buying
On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
> Befor I contacted this group, I contacted Cloudflare and asked them
> to stop creating certificates with my domain. The answer in short
> was, ... they cannot change it and as long as I am using there
> service, they will continue.
How would you
On 18/10/16 19:15, Rob Stradling wrote:
> Hi Hanno. The questions that you and others have posted are entirely
> reasonable. Sorry for the delay. Robin intends to post a reply this week.
It seems like this reply has not yet appeared?
I would like to make sure my initial question about "Where d
On 03/11/16 04:25, c...@cem.me wrote:
> Gerv, Given the discussions in the past about risks of SHA-1 issuance
> for *any* cert type, and the responses from action #1c from the March
> 2016 CA communication, are there any public plans for dealing type of
> certificate yet?
As in, do we have plans
On 28/10/16 16:11, Patrick Figel wrote:
> I found a number of SHA-1 certificates chaining up to CAs trusted by
> Mozilla that have not been brought up on this list or on Bugzilla yet.
Using the handy crt.sh link posted by Rob, I have gone through the 2016
SHA-1 issuances known to crt.sh to filter
On 03/11/16 10:30, Tim Guan-tin Chien wrote:
> PS Apologies if this is not in-scope for dev-security-policy.
I think you might be better off asking Mozilla IT :-)
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://l
Hi Gerhard,
I realise you are upset with what Cloudflare has been doing, but having
considered the matter, I think the bottom line is that the only
reasonable position for Mozilla to take is "issuances which perform a
valid domain control check are OK". We can't go policing the terms of
service of
On 03/11/16 21:17, Jakob Bohm wrote:
> Note that the GlobalSign SHA-1 intermediaries chain only to their old
> SHA-1 root which is (I believe) not used for any SHA-256 certs, except
> a cross-cert that signs their current SHA-256 root.
Nevertheless, it is still in Mozilla's trust store.
> So I su
We need to recall that currently, SHA-1 issuance is not banned directly
by Mozilla policy, but only by the BRs. And so we don't have a route to
object to certs not covered by the BRs.
On 03/11/16 18:09, Andrew Ayer wrote:
>> B) SHA-1 email certificates with no DNS names, although their lack of
>>
On 03/11/16 18:09, Andrew Ayer wrote:
> This is just as bad as signing an actual cert with SHA-1.
Add:
https://bugzilla.mozilla.org/show_bug.cgi?id=1315225 (Symantec)
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https
CT is coming to Firefox. As part of that, Mozilla needs to have a set of
CT policies surrounding how that will work. Like our root inclusion
program, we intend to run our CT log inclusion program in an open and
transparent fashion, such that the Internet community can see how it
works and how decis
Hi Jeremy,
Thanks for posting this. Mozilla had been concerned for some time about
the level of BR compliance of the Verizon-controlled PKI and their
seeming difficulties in bringing their many sub-CAs into compliance.
When DigiCert approached us when researching the potential acquisition,
they as
Here is the spreadsheet I am using to track my analysis of the SHA-1
issuances discovered in crt.sh:
https://docs.google.com/spreadsheets/d/1s0zsDjkHkPpFPd9LCtaJDgra5hqmcHmRor_sHSLl5Yg/edit
It includes notes about each incident and my determination of what to
do. At the moment, bugs are open for
On 04/11/16 21:23, Ryan Sleevi wrote:
> If there's concerns about GAs - would it be best to reply on this thread or
> start a new one per-CA?
If there's more than one CA, perhaps a new one per CA would be better,
please.
Note that marking an issuance as "GA" doesn't mean it might not be added
if
On 04/11/16 23:51, Andrew Ayer wrote:
> The March 2016 CA communication said[1]:
>
> "It has been pointed out in the mozilla.dev.security.policy forum that
> a chosen-prefix attack on SHA-1 could be used to forge a certificate if
> a CA's private key is used to sign *anything* with SHA-1."
>
> Th
It has been noted that currently, Mozilla's SHA-1 ban is implemented via
the ban in the BRs, which we require all CAs to adhere to. At the
moment, Mozilla policy simply says:
"We consider the following algorithms and key sizes to be acceptable and
supported in Mozilla products:
SHA-1 (until a
On 05/11/16 19:33, Ryan Sleevi wrote:
> My understanding was that Mozilla's implementation status was similar
> to Chrome's a year ago - that is, that it doesn't implement inclusion
> proof fetching (in the background) and that work hadn't been
> scheduled/slated yet. In that case, it's a question
On 05/11/16 13:49, Ryan Sleevi wrote:
> As noted elsewhere, the issuance of SHA-1 allows for an attacker to
> pivot the contents of the certificates, and the only mitigation is
> the EKU on the sub-CA.
>
> Are you suggesting this is GA because it wasn't clear enough to CA
> members at the time thi
On 07/11/16 10:52, Nick Lamb wrote:
> Where we don't have another way forward, I think one option is for
> CAs to replace an existing unconstrained intermediate with a newer
> one that is suitably constrained, and revoke the old one. This is
> subject to all the usual caveats about revocation and o
On 07/11/16 13:11, Phillip Hallam-Baker wrote:
> Not long after I was sitting in a conference at NIST listening to a talk on
> how shutting down DigiNotar had shut down the port of Amsterdam and left
> meat rotting on the quays etc. Ooops.
Sounds like someone got a lesson in single points of failu
Hi everyone,
We would like to reinvigorate the process of developing the next version
of Mozilla's root policy. Kathleen has been wrestling with it for some
time now, but her time is limited and her tasks are many. Other
obstructions include the "big bang" model of change we were using, the
lack o
On 07/11/16 14:34, Kurt Roeckx wrote:
> In my experience, pointing to a specific section of the BRs causes
> problems because things are moved, renumbered and so on. Other changes
> in the document also point to specific sections.
The BRs now follow RFC 3647, which AIUI specifies the title and
num
On 07/11/16 15:34, Doug Beattie wrote:
> I'd prefer a requirement for long serial numbers over a total ban on
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications
> don't have issues with that).
Can you list some of
On 07/11/16 16:13, Ryan Sleevi wrote:
> Yes, particularly for logs that may be compelled to be dishonest for
> geopolitical reasons.
As in, their dishonesty would be carefully targetted and so not exposed
by this sort of coarse checking?
Gerv
___
dev-s
On 07/11/16 20:05, Kathleen Wilson wrote:
>> It would be useful if people checked it over to make sure I have not
>> made any mistakes in conversion. The original is here, in four pages:
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
>
> Just one minor glit
On 07/11/16 17:25, Ryan Sleevi wrote:
> Yes. An 'evil log' can provide a divided split-view, targeting only
> an affected number of users. Unless that SCT was observed, and
> reported (via Gossip or some other means of exfiltration), that split
> view would not be detected.
So it is therefore impo
On 07/11/16 14:08, Gervase Markham wrote:
> Fourthly, I have triaged the issues and marked those I think are urgent
> and achievable in a reasonably short time frame with the "2.4"
> milestone. That list is here:
> https://github.com/mozilla/pkipolicy/milestone/1
Correct U
On 07/11/16 15:34, Doug Beattie wrote:
> I'd prefer a requirement for long serial numbers over a total ban on
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications
> don't have issues with that).
Actually, the BRs st
On 07/11/16 17:09, Nick Lamb wrote:
> On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote:
>> You mean EKU-constrained (e.g. to email, or OCSP only)?
>
> I was thinking also of a pathlen constraint.
Aha. So what would this look like? Something like this?
CAs may o
On 08/11/16 13:44, Doug Beattie wrote:
> GlobalSign generated some SHA-1 CAs earlier this year as part of
> normal CA lifecycle management.
Hi Doug,
This is helpful information - can you post it to the bug?
https://bugzilla.mozilla.org/show_bug.cgi?id=1315018
> Why did we not technically constr
Hi everyone,
I'd like to take some action about persistent failures to properly
disclose intermediates. The deadline for this was June, and CAs have had
a number of reminders, so there's no excuse.
Of course, if intermediates aren't disclosed, we can't be certain what
they are, but crt.sh has a g
On 08/11/16 16:28, alex.gay...@gmail.com wrote:
> Is it your intent that once OneCRL-revoked intermediates are brought
> into compliance that they'd be removed from OneCRL, or are they gone
> for good, a warning sign to those who follow.
TBD. I'm enquiring about whether it's possible to remove cer
On 08/11/16 16:47, Kurt Roeckx wrote:
> We also need to have a sorted list of them. I guess the list of crt.sh
> is acceptable. Sorting could for instance been done by sorting based on
> the SHA256.
I was planning to take the list in the order given by crt.sh at 2pm each
Monday, yes.
Gerv
__
Hi Peter,
On 08/11/16 16:53, Peter Bowen wrote:
> Can the "undisclosed" list be broken down further into "CA not
> disclosed at all" versus "missing disclosure of some
> cross-certificate"?
>
> For example, ACCVCA-130 is listed under both "Disclosed" and
> "Unconstrained id-kp-serverAuth Trust".
On 08/11/16 18:25, Peter Bowen wrote:
> No, the problem is that the Issuer reported their subCA but Salesforce
> links the audit info to certificates not to CAs. In the above
> example, there are three different CA certificates with the same
> issuer and subject, so the same (sub)CA is in both a "
On 08/11/16 19:08, Peter Bowen wrote:
> Yes, that is how one fixes it. But I'm worried that CAs may think
> they properly followed the requirement and then find themselves
> penalized. Hence my suggestion to focus on CAs that clearly have not
> even attempted to follow the requirement.
For which
On 08/11/16 19:11, Jakob Bohm wrote:
> However because all the sources are from a single entity (the UK
> government), that entity could manipulate the results, thus falsifying
> the provable randomness of the process.
I think you are bikeshedding the wrong part of this process.
The draws are tel
At the moment, Firefox recognises an EE cert as a server cert if it has
an EKU extension with id-kp-serverAuth, or if it has no EKU at all.
On 17th of Feb 2013, Mozilla published CA policy 2.1, which required
adherence to the BRs (version 1.1.5).[0]
Since the very first version of the BRs[1], EKU
On 08/11/16 16:18, Gervase Markham wrote:
> We would choose 3 certs from the list as it exists every Monday at 2pm
> UK time, using the following sources of randomness for the algorithm:
>
> 1) UK National Lottery "Lotto" numbers, not including bonus ball
> 2) UK Nati
On 08/11/16 21:09, Kathleen Wilson wrote:
> I've been exchanging email and working with just about all of these
> CAs. There have been a few problems in our Salesforce customization
> to work out, and there have been some questions about which
> intermediate certs needed to be disclosed (regarding
On 08/11/16 11:17, Gervase Markham wrote:
> Aha. So what would this look like? Something like this?
And we would need phase-in periods for both the requirements on
intermediate certs, and the requirements on end-entity certs. And the
former may have to be a bit longer than the latter, as cutt
301 - 400 of 1053 matches
Mail list logo
