Re: FW: StartCom inclusion request: next steps

[userwithuid via dev-security-policy]

On Tue, Sep 19, 2017 at 3:09 PM, Nick Lamb via dev-security-policy
 wrote:
> I have no doubt that this was obvious to people who have worked for a public 
> CA, but it wasn't obvious to me, so thank you for answering. I think these 
> answers give us good reason to be confident that a cross-signed certificate 
> in this situation would not be available to either end subscribers or 
> StartCom unless/ until the CA which cross-signed it wanted that to happen.
>
> It might still make sense for Mozilla to clarify that this isn't a good idea, 
> or even outright forbid it anyway, but I agree with your perspective that 
> this seemed permissible under the rules as you understood them and wasn't 
> obviously unreasonable.

I'm pretty sure it's already forbidden, since policy version 2.5
anyway (has effective date after the Certinomis shenanigans though):

"The CA with a certificate included in Mozilla’s root program MUST
disclose this information within a week of certificate creation, and
before any such subordinate CA is allowed to issue certificates."

2.5 added the "within a week of certificate creation" [1] . "Creation"
vs "My Safe", "Creation" wins.  :-)

[1] 
https://github.com/mozilla/pkipolicy/commit/b7d1b6c04458114fbe73fa3f146ad401235c2a1b
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Old roots to new roots best practice?

[userwithuid via dev-security-policy]

On Monday, September 18, 2017 at 1:58:03 AM UTC, Ryan Sleevi wrote:
> I agree, Gerv's remarks are a bit confusing with respect to the concern.
> You are correct that the process of establishing a new root generally
> involves the creation of a self-signed certificate, and then any
> cross-signing that happens conceptually creates an 'intermediate' - so you
> have a key shared by a root and an intermediate.
> 
> This is not forbidden; indeed, you can see in my recent suggestions to
> Symantec/DigiCert, it can and often is the best way for both compatibility
> and interoperability. Method #2 that you mentioned, while valid, can bring
> much greater compatibility challenges, and thus requires far more careful
> planning and execution (and collaboration both with servers and in
> configuring AIA endpoints)

Great, from that I gather method 1 is indeed not discouraged and maybe even 
preferred over 2, which is certainly good to hear, thanks. :-)

Wrt to the StartCom bulletpoint, I guess this was a mistake on Mozilla's part 
then and should probably be acknowledged as such, @Gerv.

> However, there is a criticism to be landed here - and that's using the same
> name/keypair for multiple intermediates and revoking one/some of them. This
> creates all sorts of compatibility problems in the ecosystem, and is thus
> unwise practice.
> 
> As an example of a compatibility problem it creates, note that RFC5280
> states how to verify a constructed path, but doesn't necessarily specify
> how to discover that path (RFC 4158 covers many of the strategies that
> might be used, but note, it's Informational). Some clients (such as macOS
> and iOS, up to I believe 10.11) construct a path first, and then perform
> revocation checking. If any certificate in the path is rejected, the leaf
> is rejected - regardless of other paths existing. This is similar to the
> behaviour of a number of OpenSSL and other (embedded) PKI stacks.
> Similarly, applications which process their own revocation checks may only
> be able to apply it to the constructed path (Chrome's CRLSets are somewhat
> like this, particularly on macOS platforms). Add in caching of
> intermediates (like mentioned in 4158), and it quickly becomes complicated.
> 
> For this reason - if you have a same name/key pair, it should generally be
> expected that revoking a single one of those is akin to revoking all
> variations of that certificate (including the root!)

Hmmm, I think I see the point you are making here, in general. Like, if both a 
revoked a non-revoked version of an intermediate are sent by a server, it might 
potentially break a client that does "naive" revocation checking like you 
described; path first, then check (e.g. openssl?). Worse, a client that has an 
intermediate cache _and_ does "naive" revocation checking might break long 
after the revoked one has been last sent (maybe the revoked one even came from 
a different server altogether). That would suck and the only server-side fix 
would be to switch to a cert signed by a new intermediate. Do you know a 
real-world client example for the latter though? Old Apple as you mentioned? Or 
was this just theoretical?

Either way, in the specific case, StartCom, this criticism seems to be 
inapplicable, as the revoked one was never deployed in the first place.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Old roots to new roots best practice?

[userwithuid via dev-security-policy]

Forgot the links:

[1] 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/hNOJJrN6WfE
[2] 
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/RJHPWUd93xE/RqnC3brRBQAJ
[3] 
https://crt.sh/?spkisha256=fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2
[4] 
https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aefa40a53406a3aec26039efa6b2e0e7244c1
[5] 
https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf597f12d2cad2f63d1a4aa37493800ffb80
[6] 
https://crt.sh/?spkisha256=f7cd08a27aa9df0918b4df5265580ccee590cc9b5ad677f134fc137a6d57d2e7
[7] 
https://crt.sh/?spkisha256=60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
[8] 
https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a4fcce203d4c2eddcaa4013763b5a23d81f
[9] https://bugzilla.mozilla.org/show_bug.cgi?id=1311832
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Old roots to new roots best practice?

[userwithuid via dev-security-policy]

Quoting Gerv from the latest StartCom thread [1]:
"* The key for their new root certificate was also used in a couple of
intermediates (one revoked as it was done incorrectly - again, lack of
testing!). While this is probably not a policy violation, it's not good
practice."

Everyone including StartCom itself acknowledges that the one "done 
incorrectly", the revoked one, shouldn't have happened. This thread is not 
about that.

I want to understand the meaning and reasoning for the rest of the bullet point 
as it makes no sense to me. I asked this before in the StartCom/Certinomis 
thread [2], where Kathleen said the same as Gerv, but it got no response, so 
I'm trying again.

I can think of 3 ways to support old and new roots in parallel:

1.
In the other thread I mentioned that major CAs like Amazon [3], Comodo [4] and 
GlobalSign [5] also seem to use the key for a root cert in an "intermediate". 
This is used to create the following trust paths:

modern client: new root (in store) --- issuing intermediate A0 --- leaf
legacy client: old root (in store) --- new root! (same key/name, but different 
cert; "intermediate") --- issuing intermediate A0 --- leaf

2.
The alternative solution seems to be to "reuse" the key of the issuing 
intermediate instead, as done by e.g. Entrust [6] or Let's Encrypt/IdenTrust 
[7]. Paths:

modern: new root --- issuing intermediate A1 (eg signed by ISRG Root) --- leaf
legacy: old root --- issuing intermediate A2 (same key/name as A1, different 
cert, eg signed by IdenTrust) --- leaf

3.
Yet another solution would be to have no key/name sharing @ CA level, and 
instead sign a leaf with multiple keys during the issuing process to create 
multiple unrelated paths. That would result in having more than one leaf cert 
though, so it is not a viable solution in general.

modern: new root --- issuing intermediate N --- leaf L1
legacy: old root --- issuing intermediate O --- leaf L2 (different cert, but 
possibly same key)



Looks like StartCom chose 1. [8] instead of 2. This was explicitly permitted by 
Mozilla in [9]. So why are they now criticized for it? Am I missing something, 
did I get it wrong above? In general: Is 1. really "not good practice" to 
switch roots, do Mozilla or others prefer 2.?*



* I sure hope not. Option 1 implicitly makes server admins provide either only 
the new path, or both old and new paths, never just the old one. Option 2 
allows "only old" as well. Since trust stores keep old roots for compat, "only 
old" works when admins test it, so they can use that and forget "new". Hence 
you can't easily remove legacy roots from the trust store because compat; 
chicken/egg. (unless you get the right=new intermediates into the trust 
store/interm cache/validation path somehow; that's ugly but sometimes possible 
e.g. with NSS you can have neutral trust entries and iiuc AIA chasing could 
also do this?).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[userwithuid via dev-security-policy]

On Tuesday, August 15, 2017 at 12:32:01 PM UTC, Gervase Markham wrote:
> OneCRL does not obsolete certdata.txt-based distrust because not
> everyone checks OneCRL. While we can't add every cert in OneCRL to
> certdata.txt, we should add the big dis-trusts to it. Do you think
> there's anything missing?

I'm not following this CA stuff for that long, but one thing that comes to mind 
is the us gov pki. The symantec cross-sign has expired by now and the identrust 
one only has 5 months left, so going by current public info this will resolve 
itself soon. Still, for 2 years now a huge, intransparent, complex subtree is 
(probably) blocked for OneCRL clients, but trusted for non-OneCRL (+non-OCSP) 
users. Imho this is/was a little more high-profile than most other entries.

Another situation: Old Wosign/StartCom roots are slated to be removed from 
certdata soon afaik. Finally, end of that story, right? But old WoSign has a 
revoked cross-signed by Certum until 2020. So Firefox and OCSP clients will get 
the expected result: No more old WoSign. "Just certdata"-consumers will still 
have it trusted and hardly anybody will know that this is happening or how. 
Candidate for addition?

In general: When I read the messages on this list, I get the following 
impression:

1. GOOD: Revocation alone is "not really enough", mis-issuance is still bad and 
it reflects badly on a CA if there are too many issues or their handling is 
poor.
2. HOWEVER: In practice, once a cert is revoked and added to OneCRL, both the 
CA and Mozilla consider that particular issue resolved. A revoked cert or 
subtree is considered "not in scope" any more (and understandably so, there 
isn't much more that can be done on the technical level save removing the 
entire root for really bad cases).

So to me it kinda felt like non-OneCRL is not taken into account by Mozilla any 
more. But since you said certdata distrust might still be used, a suggestion:

The Mozilla workflow seems to be missing a step that checks whether a revoked 
subCA will 1. keep issuing certs (e.g. I just read up on the Disney CA that was 
revoked, then started issuing non-compliant certs) and 2. whether exisiting 
certs at the time of revocation had critical issues (e.g. failed validation). 
In both cases certdata addition should be at least considered. Otoh, additions 
stemming from e.g. the recent reports seem to be good candidates for 
OneCRL-only distrust. Same if a subCA just moved roots or stopped operating and 
that was the reason for revocation.

Basically: Figure out/inquire why the revocation happened and classify as high 
or low risk. Maybe Mozilla's policy could be adjusted to require CAs to provide 
such an explanation on revocation? I'm aware that there is a "revocation 
reason" in OCSP already, but that is insufficient (e.g. "cessation of 
operation" for identrust federal bridge cross...).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[userwithuid via dev-security-policy]

On Friday, August 4, 2017 at 12:27:13 AM UTC, Kathleen Wilson wrote:
> Along this line of discussion, I have not felt comfortable with StartCom's 
> current root inclusion request (bug #1381406), because Hanno raised a concern 
> about the private key used by the new root is also used by two intermediate 
> certificates, one of them revoked. This doesn't see like good practice to me, 
> and I'm not sure that Inigo's response is sufficient.

OK, maybe I'm just not getting it but what exactly *is* the issue that was 
brought up in that bug?

I would think that this is, as the StartCom response seems to confirm, just the 
way you cross-sign new roots with existing ones? Old roots signing new roots is 
done by other CAs as well and I'm not aware of any talk or rule that this is 
discouraged or forbidden?

My understanding is this (please correct me if I'm wrong):

Hanno's crtsh link [0] just has a spkisha256 parameter. The list contains the 
root's self-sign and two instances where the root was signed by an old StartCom 
root.

I get similar output with the spkisha256 of other trusted roots, i.e.:

Amazon [1]: New roots signed with old Starfield Services Root that they bought
Commodo [2]: Newer roots signed with their old AddTrust Root
GlobalSign [3]: R3 root signed with their R1 root

How, if not like this, can roots be cross-signed at all, technically? How are 
the above 3 examples different from the way StartCom did it?

(If they aren't, I think it's important that the record is set straight and 
this specific thing doesn't appear in the real or mental list of things that 
new StartCom did wrong... If they are, disregard of course. :-D ).



[0] 
https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a4fcce203d4c2eddcaa4013763b5a23d81f
[1] 
https://crt.sh/?spkisha256=fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2
[2] 
https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aefa40a53406a3aec26039efa6b2e0e7244c1
[3] 
https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf597f12d2cad2f63d1a4aa37493800ffb80
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[userwithuid via dev-security-policy]

On Wednesday, July 26, 2017 at 12:55:06 AM UTC, David E. Ross wrote:
> Under the Servers tab for Certificate Manager, I see several root
> certificates whose expiration dates have passed.  I believe these were
> all marked untrusted at one time.  For example, I see six DigiNotar
> certificates, CNNIC's MCSHOLDING TEST, Equifax's MD5 Collisions, among
> others.  Is it safe to delete these?

IIRC, Mozilla just likes to keep expired distrust around because it cannot be 
overridden in the UI, whereas expired or unknown certs might be something a 
regular user might consider not that big of a deal and click through.


In this context @Mozilla: Those additional distrust entries are coming from 
NSS, but they are all pre-OneCRL afaics. Is this coincidence (= there wasn't 
any "high-profile" enough distrust warranting nss addition) or has the 
certdata-based distrust been entirely obsoleted by OneCRL (= there will never 
be any new distrust entries in certdata)?

I'm asking because some/most linux distros consume certdata, and they usually 
do have some blacklist capability where they put the certdata based distrust, 
but I don't know of any that parses OneCRL. I guess they all should, right?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[userwithuid via dev-security-policy]

WRT to the deadlines: If the decision is to sync up, I think it's worth noting 
that Firefox probably needs to release 2-3 weeks after a Chrome "release date" 
to achieve this in practice.

Why? Firefox updates take ~10days from release date to reach previous version 
numbers. Chrome _can_ do it in the same time, but sometimes they slow update 
propagation considerably - and the distrust events could very well be reasons 
to do this.

Take for example Chrome 57: Release date for desktop was March 9 [1], but 
propagation was throttled heavily for the first ~20 days, resulting in a total 
of ~30 days. [2] Chrome 57 for Android, supposedly released March 16 - always a 
week later than desktop! - was also held back for most? users for ~3-4 weeks 
iirc (can't find a graph right now, sorry).

So unless Mozilla is eager to deal with most of the immediate outfall of the 
trust changes on its own (at which point we might as well set stricter 
deadlines), it should strategically fall behind.

Dates in question:
* Firefox 60 on 2018-05-01 for old PKI notBefore >=2016-06 -> already close, 
only 2 weeks after
* Firefox 64 on 2018-11-27 for the full distrust -> 5 weeks after. Bonus: All 
the 1-year certs from the old PKI will have expired as well.

[1] 
https://chromereleases.googleblog.com/2017/03/stable-channel-update-for-desktop.html
[2] 
http://gs.statcounter.com/browser-version-market-share/desktop/worldwide/#daily-20170301-20170501





On Monday, July 31, 2017 at 2:01:57 PM UTC, Gervase Markham wrote:
> On 29/07/17 23:45, Peter Bowen wrote:
> > First, when the server authentication trust will bits be removed from
> > the existing roots.  This is of notable importance for non-Firefox
> > users of NSS.  Based on the Chrome email, it looks like they will
> > remove trust bits in their git repo around August 23, 2018.  When will
> > NSS remove the trust bits?
> 
> The NSS trust store represents Mozilla's decisions about what is
> trustworthy. However, particularly if we match Chrome's dates, there is
> a slightly unusual situation as we have taken a decision on
> trustworthiness but, for other reasons, Firefox still trusts those certs
> for a period. So one might well ask, should the decision be implemented
> in NSS earlier than, or at the same time as, or even later than, Firefox
> implements it? A good question.

If you enjoy making things harder for other people you can go with earlier :-P 
. Seriously though, that would only make sense from a Mozilla release process 
perspective but is totally unexpected and annoying for any other NSS consumer - 
they will just have to postpone that NSS update or restore the roots 
temporarily.

I think it makes most sense to land Firefox internal distrust shortly before 
branching, like Chrome, use beta for gauging impact, release, then ~2 weeks 
after release date do a NSS point release with only the certdata changes for 
other consumers and future Firefox versions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: An alternate perspective on Symantec

[userwithuid via dev-security-policy]

Inspired by David's message, 2 suggestions for the Symantec plan:

1. Mozilla - and ideally Google as well - should clearly and explicitly 
communicate in the official statement on this that the "new" Symantec will 
still be strictly monitored even after the current remediation plan has been 
implemented. Their issue history still very much counts, potentially resulting 
in much harsher responses to future policy violations than would be the case 
for first-time offenders/other CAs. This is to counter the potential 
misconception (aka marketing) that everything is totally fine now.

2. Having Symantec inform their subscribers, as David mentions, is a great 
idea. Specifically, I think Symantec should be required to make their 
subscribers aware of the Mozilla-written! statement regarding the future of 
their CA, soon (<=1 month?) after its release. This is to prevent too many 
subscribers from getting caught by surprise in the future (see StartCom), to 
give them a chance to see more than one side, CA view _and_ Mozilla view, and 
to ensure they know they are Symantec subscribers in the first place (RapidSSL 
cert chaining to a GeoTrust root bought from some reseller = Symantec? yeah, 
totally obvious...).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec response to Google proposal

[userwithuid via dev-security-policy]

On Tuesday, June 6, 2017 at 2:03:29 PM UTC, Gervase Markham wrote:
>
> 1) Scope of Distrust
> 
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted until expiry.
> Rationale for change: if transparency is enough to engender trust, that
> principle should be applied consistently. This also significantly
> reduces the revalidation burden.

As mentioned in the other Symantec thread, right now Firefox doesn't do CT so 
notBefore >=2016-06 is the non-CT way of at least partially distrusting the 
old/unknown PKI soon-ish. I don't think it's a good idea to just broaden this 
to 2015-01 unless we know we can do CT by 2018-02. (Not sure if we'd be able to 
defend 2016-06 alone if Google agrees to do 2015-01 though)

Then again, also in the other thread, you said "Mozilla would wish" the old PKI 
to be distrusted "sooner than November 2020" and you "expect it to be some time 
in 2018". Which I found to be a very bold proposition. Has Symantec commented 
on that yet? If not, can you make them? :-) In the event that we actually get 
2018, allowing some older certs for a few more months might be worth conceding. 
A little less technically enforcable risk reduction from 2018-02 to 2018-?? in 
exchange for the "real deal" sooner than expected sounds good.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Plan for Symantec posted

[userwithuid via dev-security-policy]

On Sunday, May 21, 2017 at 11:31:54 PM UTC, Michael Casadevall wrote:
> There's also a fair number of points dealing with who can sign and for
> what while Symantec spins up the new roots (which the Google proposal
> says a trusted third party CA signed by Symantec").
> 
> I'm against this point specifically because third-party CA operations is
> how we got into this mess.

I agree with your general concern, but the OP states:
"These sub-CAs must be operated by a non-affiliated organization that operates 
roots currently trusted in the Android and Chrome OS trust stores that have 
been trusted for a period of at least two years."

This to me sounds very similar in theory to Certum/Asseco doing OV for WoSign, 
which on this list has been considered OK. Personally, I'd rather not have any 
of this CA mixing, 3rd-party delegating, cross-signing of whole trees, 
root-buying etc. but all this stuff seems to be an integral part of current 
industry practice.+

I say in theory because Symantec's "good arguments" (aka monies) have the 
potential to make the selected CA their bi...dding doer by means of contract in 
reality. What else is new though? I'm positive Symantec would have always found 
some business arrangement with another CA for their customers that want > 9 
months cert lifetime and/or EV under Google's first proposal, so we would have 
gotten some "Managed CA" one way or the other. Worst case it would have been 
mixed in with other certs, not having a dedicated subCA or other marker. Now 
it's explicit, separate and even has some additional rules.

NSS* already trusts that other CA to do proper validation right now, and they 
might just be smart enough to realize that they will be watched way more 
closely when Symantec starts using them to not do anything totally stupid. I 
honestly think that this "Managed CA" will get more practical oversight both by 
auditors and by the community than most of the roots in NSS.



+ Appreciation footnote for the DTP discussion @ cabf and the 
GlobalSign->Google root transfer discussion on here
* Android trust store seems to be a subset of NSS'
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

[userwithuid via dev-security-policy]

On Wednesday, May 17, 2017 at 11:24:54 AM UTC, Gervase Markham wrote:
> Well, such contacts are normally per CA rather than per root. I guess we
> could add it on the CA's entry.

Tbh, I'm not really familiar with your salesforce setup, I was just using this 
as a stand-in for "place where CA can be made to keep it current". :-)

> Well, I want to make sure that people who want to report e.g. a bad cert
> found in the wild know where to go. This was triggered by an event where
> Microsoft wanted to report something to GoDaddy (IIRC) but using the
> wrong contact.

So the intent was really:

How can an external entity (= not the certificate owner or authorized party) 
report a security issue, abuse scenario or policy violation with regards to 
certificates you issued? Specifically, what contact email address or webpage 
can be used to ensure a timely and competent response?

(plainly: how to reach "tech" or "compliance", not 
sales/marketing/customer-support/general/...)

> > IMHO, a wiki page with manually copied info has a good chance to get
> > stale as CAs change their documents, websites, primary domains, etc.
> 
> It's true, but the other option is "dig in my CP/CPS".

But there could be more "other options":

dig yourself << community collected and maintained info < CA verified community 
info < info CAs are "forced" to maintain, policed by community

So I guess my second choice - after getting CAs to unbundle this specific info 
from their pdfs and maintain it via the CCADB (or wherever else it makes sense) 
- would be to go ahead with the manually created wiki page and make them 
confirm it regularily via CA communications. Then there is still a degree of 
accountability for the correctness.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

[userwithuid via dev-security-policy]

After skimming the responses and checking a few CAs, I'm starting to wonder: 
Wouldn't it be easier to just add another mandatory field to the CCADB (e.g. 
"revocation contact"), requiring $URL or $EMAIL via policy and just use that to 
provide a public list?

It seems to me that most revocation related procedures are very specific to 
CA-customers (e.g. log in and use the revoke button) and often not even TLS 
related (e.g. send a document signed with key you want to revoke, use the 
revocation password you got when creating the email cert, ...). I think it's 
not your intention for the wiki page to capture that, or is it?

>From what I can see, for non-customers the "instructions" - if there are any - 
>really seem to amount to: A) Send email with cert info + reason you suspect 
>misuse, we'll check or B) use web form to do the same.

IMHO, a wiki page with manually copied info has a good chance to get stale as 
CAs change their documents, websites, primary domains, etc.

(That being said, trying to use CPS urls from the CCADB [0] I got some 404s and 
some 30* lead nowhere as well. Also some CAs link an outdated version when the 
website has a WAY more recent one, though that might be because of the English 
vs native lang situation. Point is, CCADB entries might also be outdated, but 
at least that will be a policy violation now, right?).

[0] https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Find a 5-year certificate

[userwithuid via dev-security-policy]

> https://bugzilla.mozilla.org/show_bug.cgi?id=908125 .
> 
> Gerv

Wow, embarrassingly weak google-fu on my part... Sorry and thanks!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Find a 5-year certificate

[userwithuid via dev-security-policy]

In this context, I was wondering: Has there been a discussion yet on Firefox 
enforcing cert lifetime in code not just via policy?

Most everything seems to be in place already due to EV, but DV doesn't have a 
limit atm. [0]

Now in practice, thanks to killing sha1, most of those legacy certs are 
probably distrusted anyway. But then again, backdating is technically possible, 
until full CT can provide protection in ~4 years iiuc, and it's a pretty 
stealthy way for CAs to subvert current guidelines (unless you do it 
WoSign-style I guess...)

Limiting to 60 months could be done right now as a sanity check and shouldn't 
cause any problems, right?

[0] 
https://github.com/mozilla/gecko-dev/blob/455ab646d315d265b4c0c3f712a69aae40985fcf/security/certverifier/NSSCertDBTrustDomain.cpp#L1112
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy