Unretrievable CPS documents listed in CCADB

[Corey Bonnell]

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 particular, “the URLs to such CPs, CPSes and audits, and any metadata about them such as the name of the auditor or the date of the audit, need to be updated as new information become available.”

The current AllCertificateRecordsReport.csv was downloaded and the CPS URLs for all unrevoked intermediate and root certificates were extracted. Each extracted CPS URL was then requested via HTTP GET using cURL and the HTTP response status code recorded. Below is a list of all CPS URLs which return a HTTP status code of 400 or greater:

"Row number", "CA Owner", "Certificate Name", "CPS URL", "HTTP status code"
7, "AC Camerfirma, S.A.", "Chambers of Commerce Root", http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_EN_v_1_2_3.pdf, 404
191, Atos, "Atos TrustedRoot 2011", https://pki.atos.net/Download/AtosTrustedCACPSv1.9.0.pdf, 404
258, "Autoridad de Certificacion Firmaprofesional", "SIGNE Autoridad de Certificacion", http://www.signe.es/wp-content/uploads/2018/08/DPC_SIGNE_2.1-180731.pdf, 404
262, Buypass, "Buypass Class 2 CA 1", http://www.buypass.com/home/support/ca-documentation-legal, 404
466, "Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)", "S-TRUST Authentication and Encryption Root CA 2005:PN", http://www.s-trust.de/stn-cps/stn_cps.pdf, 404
468, "Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)", "TC TrustCenter Class 3 CA II", https://www.s-trust.de/stn-cps, 404
594, DigiCert, "ADACOM CA for EU Qualified e-Seals", https://pki.adacom.com/repository/en/CPS/files/Certification_Practice_Statement_for_EU_Qualified_certificates_v3.pdf, 404
634, DigiCert, "Allgeier IT Solutions CA", https://www.s-trust.de/ablage_download_dokumente/ablage_pdf/S-TRUST_STN_CPS_V3_87.pdf, 404
741, DigiCert, "Belgium Root CA2", https://stage-pki.belgium.be/resources/PKI-BelgiumRootCA-CPS-v1.2.pdf, 404
1394, DigiCert, "Government AA", https://stage-pki.belgium.be/resources/Government-CA-Certification-Practice-Statement-v1.0.pdf, 404
1546, DigiCert, "Microsoft IT SSL CA 1", https://www.microsoft.com/pki/mscorp/cps/Microsoft%20IT%20PKI%20CP-CPS%20for%20SSL%20Ver%201%203%20January%202015.htm, 404
1551, DigiCert, "Microsoft IT SSL SHA2", http://www.microsoft.com/pki/mscorp/cps/Microsoft%20IT%20PKI%20CP-CPS%20for%20SSL%20Ver%201%203%20January%202015.htm, 404
2494, "Financijska agencija (Fina)", "Fina Root CA", http://rdc.fina.hr/QTSA2017/FinaQTSA, 404
2815, "Government of France (ANSSI, DCSSI)", IGC/A, http://www.ssi.gouv.fr/site_article15.html, 404
2991, "Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA)", "Tunisian Root Certificate Authority - TunRootCA2", http://www.tuntrust.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-08.pdf, 404
3209, "Microsec Ltd.", "e-Szigno Class2 CA 2017", https://static.e-szigno.hu/docs/szsz--fok--sea--EN--v2.8.pdf, 404
3211, "Microsec Ltd.", "e-Szigno Class3 CA 2017", https://static.e-szigno.hu/docs/szsz--fok--sig--EN--v2.8.pdf, 404
3216, "Microsec Ltd.", "e-Szigno Qualified CA 2017", https://static.e-szigno.hu/docs/szsz--min--sig--EN--v2.8.pdf, 404
3217, "Microsec Ltd.", "e-Szigno Qualified Organization CA 2017", https://static.e-szigno.hu/docs/szsz--min--sea--EN--v2.8.pdf, 404
3308, "Pos Digicert Sdn. Bhd (Malaysia)", "PosDigicert Class 2 Root CA G2", https://www.posdigicert.com.my/public/uploads/files/CPS-Rev-60.pdf, 404
3442, "SECOM Trust Systems CO., LTD.", http://www.valicert.com/, https://repository.secomtrust.net/rootrepository/CPSen.pdf, 404
3445, "SECOM Trust Systems CO., LTD.", "Security Communication EV RootCA1", https://repository.secomtrust.net/EV-Root1/index.html, 404
4526, "T-Systems International GmbH (Deutsche Telekom)", "Deutsche Telekom AG Issuing CA 01", http://corporate-pki.telekom.de/cps/cps.htm, 403
4528, "T-Systems International GmbH (Deutsche Telekom)", "Deutsche Telekom AG Issuing CA 01", http://corporate-pki1.telekom.de/cps/cps.htm, 403
5242, "Telia Company (formerly TeliaSonera)", "Sonera Class1 CA", http://repository.trust.teliasonera.com/CPS/index3.html, 404
5388, "WoSign CA Limited", "CA WoSign ECC Root", http://www.wosign.com/policy/wosign-policy-1-2-12.pdf, 403
5436, Zetes, "ZETES TSP ROOT CA 001", http://repository.tsp.zetes.com/Zetes, 404

Given that these URLs return error HTTP status codes, I do not believe these CCADB entries comply with CCADB Policy (and by extension, Mozilla Policy).

As an aside, I noticed that several URLs listed in CCADB are “Legal Repository” web page URLs that contain a list of many CP/CPS documents. My recommendation is to slightly amend CCADB Policy to require CAs to provide URLs to the specific document in question rather than a general “Legal Repository” page, where it is left up to the reader to decide which hyperlink on the page is the correct document.

Thanks,
Corey

[Andrew Ayer]

On Thu, 2 May 2019 18:53:39 -0700 (PDT)
Corey Bonnell via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> As an aside, I noticed that several URLs listed in CCADB are “Legal
> Repository” web page URLs that contain a list of many CP/CPS
> documents. My recommendation is to slightly amend CCADB Policy to
> require CAs to provide URLs to the specific document in question
> rather than a general “Legal Repository” page, where it is left up to
> the reader to decide which hyperlink on the page is the correct
> document.

+1. It's often a real hassle to find the CP/CPS for a CA. Linking
directly to the document would help a lot.

[Sándor dr. Szőke]

2019. május 3., péntek 3:53:49 UTC+2 időpontban Corey Bonnell a következőt írta:
> 3209, "Microsec Ltd.", "e-Szigno Class2 CA 2017", https://static.e-szigno.hu/docs/szsz--fok--sea--EN--v2.8.pdf, 404
> 3211, "Microsec Ltd.", "e-Szigno Class3 CA 2017", https://static.e-szigno.hu/docs/szsz--fok--sig--EN--v2.8.pdf, 404
> 3216, "Microsec Ltd.", "e-Szigno Qualified CA 2017", https://static.e-szigno.hu/docs/szsz--min--sig--EN--v2.8.pdf, 404
> 3217, "Microsec Ltd.", "e-Szigno Qualified Organization CA 2017", https://static.e-szigno.hu/docs/szsz--min--sea--EN--v2.8.pdf, 404

The filenames werw incorrect in the CCADB.

I have corrected and checked all url-s.

Sorry for causing problems.

Sándor Szőke
Microsec

[(RS) Tyler Schroder]

Hi Corey,

FWIW, at least one of those CAs are no longer active, such as 5388 WoSign: https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ - do old CAs get removed from CCADB or marked inactive in that system?

I do like the idea of linking the specific document over the general repo page.

Regards,

Tyler

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Corey Bonnell via dev-security-policy
Sent: Thursday, May 2, 2019 9:54 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: [EXT]Unretrievable CPS documents listed in CCADB

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 particular, “the URLs to such CPs, CPSes and audits, and any metadata about them such as the name of the auditor or the date of the audit, need to be updated as new information become available.”

The current AllCertificateRecordsReport.csv was downloaded and the CPS URLs for all unrevoked intermediate and root certificates were extracted. Each extracted CPS URL was then requested via HTTP GET using cURL and the HTTP response status code recorded. Below is a list of all CPS URLs which return a HTTP status code of 400 or greater:

"Row number", "CA Owner", "Certificate Name", "CPS URL", "HTTP status code"
7, "AC Camerfirma, S.A.", "Chambers of Commerce Root", http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_EN_v_1_2_3.pdf, 404
191, Atos, "Atos TrustedRoot 2011", https://pki.atos.net/Download/AtosTrustedCACPSv1.9.0.pdf, 404
258, "Autoridad de Certificacion Firmaprofesional", "SIGNE Autoridad de Certificacion", http://www.signe.es/wp-content/uploads/2018/08/DPC_SIGNE_2.1-180731.pdf, 404
262, Buypass, "Buypass Class 2 CA 1", http://www.buypass.com/home/support/ca-documentation-legal, 404
466, "Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)", "S-TRUST Authentication and Encryption Root CA 2005:PN", http://www.s-trust.de/stn-cps/stn_cps.pdf, 404
468, "Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)", "TC TrustCenter Class 3 CA II", https://www.s-trust.de/stn-cps, 404
594, DigiCert, "ADACOM CA for EU Qualified e-Seals", https://pki.adacom.com/repository/en/CPS/files/Certification_Practice_Statement_for_EU_Qualified_certificates_v3.pdf, 404
634, DigiCert, "Allgeier IT Solutions CA", https://www.s-trust.de/ablage_download_dokumente/ablage_pdf/S-TRUST_STN_CPS_V3_87.pdf, 404
741, DigiCert, "Belgium Root CA2", https://stage-pki.belgium.be/resources/PKI-BelgiumRootCA-CPS-v1.2.pdf, 404
1394, DigiCert, "Government AA", https://stage-pki.belgium.be/resources/Government-CA-Certification-Practice-Statement-v1.0.pdf, 404
1546, DigiCert, "Microsoft IT SSL CA 1", https://www.microsoft.com/pki/mscorp/cps/Microsoft%20IT%20PKI%20CP-CPS%20for%20SSL%20Ver%201%203%20January%202015.htm, 404
1551, DigiCert, "Microsoft IT SSL SHA2", http://www.microsoft.com/pki/mscorp/cps/Microsoft%20IT%20PKI%20CP-CPS%20for%20SSL%20Ver%201%203%20January%202015.htm, 404
2494, "Financijska agencija (Fina)", "Fina Root CA", http://rdc.fina.hr/QTSA2017/FinaQTSA, 404
2815, "Government of France (ANSSI, DCSSI)", IGC/A, http://www.ssi.gouv.fr/site_article15.html, 404
2991, "Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA)", "Tunisian Root Certificate Authority - TunRootCA2", http://www.tuntrust.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-08.pdf, 404

3209, "Microsec Ltd.", "e-Szigno Class2 CA 2017", https://static.e-szigno.hu/docs/szsz--fok--sea--EN--v2.8.pdf, 404
3211, "Microsec Ltd.", "e-Szigno Class3 CA 2017", https://static.e-szigno.hu/docs/szsz--fok--sig--EN--v2.8.pdf, 404
3216, "Microsec Ltd.", "e-Szigno Qualified CA 2017", https://static.e-szigno.hu/docs/szsz--min--sig--EN--v2.8.pdf, 404
3217, "Microsec Ltd.", "e-Szigno Qualified Organization CA 2017", https://static.e-szigno.hu/docs/szsz--min--sea--EN--v2.8.pdf, 404

3308, "Pos Digicert Sdn. Bhd (Malaysia)", "PosDigicert Class 2 Root CA G2", https://www.posdigicert.com.my/public/uploads/files/CPS-Rev-60.pdf, 404
3442, "SECOM Trust Systems CO., LTD.", http://www.valicert.com/, https://repository.secomtrust.net/rootrepository/CPSen.pdf, 404
3445, "SECOM Trust Systems CO., LTD.", "Security Communication EV RootCA1", https://repository.secomtrust.net/EV-Root1/index.html, 404
4526, "T-Systems International GmbH (Deutsche Telekom)", "Deutsche Telekom AG Issuing CA 01", http://corporate-pki.telekom.de/cps/cps.htm, 403
4528, "T-Systems International GmbH (Deutsche Telekom)", "Deutsche Telekom AG Issuing CA 01", http://corporate-pki1.telekom.de/cps/cps.htm, 403
5242, "Telia Company (formerly TeliaSonera)", "Sonera Class1 CA", http://repository.trust.teliasonera.com/CPS/index3.html, 404
5388, "WoSign CA Limited", "CA WoSign ECC Root", http://www.wosign.com/policy/wosign-policy-1-2-12.pdf, 403
5436, Zetes, "ZETES TSP ROOT CA 001", http://repository.tsp.zetes.com/Zetes, 404

Given that these URLs return error HTTP status codes, I do not believe these CCADB entries comply with CCADB Policy (and by extension, Mozilla Policy).

As an aside, I noticed that several URLs listed in CCADB are “Legal Repository” web page URLs that contain a list of many CP/CPS documents. My recommendation is to slightly amend CCADB Policy to require CAs to provide URLs to the specific document in question rather than a general “Legal Repository” page, where it is left up to the reader to decide which hyperlink on the page is the correct document.

Thanks,
Corey
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Ben Wilson]

I'm against having to continually update the exact URL of the CP and CPS in the CCADB. It's pretty easy to find the current CP and CPS from a legal repository. Plus, if we point to an exact one in the CCADB, it might not be the one that is applicable to a given certificate that was issued prior to the most current CPS. In other words, you should look at when the certificate was issued and then figure out which CPS is applicable.

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Andrew Ayer via dev-security-policy
Sent: Thursday, May 2, 2019 8:16 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Unretrievable CPS documents listed in CCADB

On Thu, 2 May 2019 18:53:39 -0700 (PDT)
Corey Bonnell via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> As an aside, I noticed that several URLs listed in CCADB are “Legal
> Repository” web page URLs that contain a list of many CP/CPS
> documents. My recommendation is to slightly amend CCADB Policy to
> require CAs to provide URLs to the specific document in question
> rather than a general “Legal Repository” page, where it is left up to
> the reader to decide which hyperlink on the page is the correct
> document.

+1. It's often a real hassle to find the CP/CPS for a CA. Linking
directly to the document would help a lot.

[Jakob Bohm]

The issue of identifying the proper CPS for older certificates raises
the important overall question of how this should be managed on an
industry wide basis:

Note: All examples use numerically invalid values, such as OIDs
beginning with "5." or non-existent dates in the Gregorian calendar.

Some CCADB future policy ideas:

Option 1: The policy extension in each end cert could contain a specific
OID for each policy version, preferably in a systematic way. For
example, if the OID the DV policy of a specific CA sub-hierarchy was
5.4.3.2.1 Then the policy OID for policy release N (consisting of
CPS version N and the CP version it references) could be 5.4.3.2.1.N .

Software running on the CCADB or in services like crt.sh could and
should scan this data periodically to provide useful data and check
for attempts to fraudulently rewrite history.

For this option, CCADB manual entry data would specify the latest
OID and a URL formatting pattern to get any previous policy version by
its number.

TODO: This may or may not interfere with other PKI or root store
policies that require or presume a static OID for the lifetime of the
issuing CA. It also wouldn't work for older policies that were not
mapped in this way.

TODO: This would not reflect subsequent changes in revocation policy
affecting already issued certificates.


Option 2: At any time, the latest CPS document for each overall policy
should contain, in a Mozilla or BR specified standard section number,
a standard formatted table of the issuance date range covered by each
previous CPS version (Assuming a hypothetical rule that a CPS must
explicitly reference the exact applicable CP, if any). Something
like:

55.66.77.88 Past versions of this document:
+-----+----------+------------------+---------------------------+
| ver | eff date | document SHA-512 | Notes |
+-----+----------+------------------+---------------------------+
|1.0 |1996-02-30|xxxxxxxxxxxxxxxxxx| VeryOld hierarchy founded |
| | |xxxxxxxxxxxxxxxxxx| |
|1.1 |1997-02-30|xxxxxxxxxxxxxxxxxx| Timestamping CAs added |
| ............................................................. |
|25.2 |2019-04-31|xxxxxxxxxxxxxxxxxx| Annual review, no changes |
| | |xxxxxxxxxxxxxxxxxx| |
+-----+----------+------------------+---------------------------+

Software running on the CCADB or in services like crt.sh could and
should scan those tables periodically to provide useful data and check
for attempts to fraudulently rewrite history.

For this option, CCADB manual entry data would specify a fixed URL
for the latest version and a URL formatting pattern to get any
previous version by its number. For example
https://repository.example.com/repo/mailCPS-latest.pdf
https://repository.example.com/repo/mailCPS-%V.pdf

TODO: How to specify that a CA (root or intermediary) has been
moved to another policy category, e.g. from "Digicert active S/MIME
roots CPS" to "Digicert revocation-only S/MIME CAs policy" or
"Digicert archived mail signature CAs policy".

TODO: How to specify that some past policy versions used a different
file format (such as text/plain or text/html) for the canonical
binding document form.

Option 3: Upon each policy change or renewal, the CA shall notify the
root programs by appending information similar to the table in option
2, plus a permanent URL in an appropriate CCADB table, visible to the
public. [ This is very similar to current policy ]

CCADB scripts would automatically extract the latest versions
for the old single-version CSV files. CCADB security settings should
prevent CAs from retroactively rewriting history, and corrections
need to be confirmed by the (CA) root program administrators.

Option 4: The repositories on each CA website must include a specific
micro-format to allow programmatically extracting information similar
to the table in option 2, including the URLs.

Software running on the CCADB or in services like crt.sh could and
should scan those pages periodically to provide useful data and check
for attempts to fraudulently rewrite history.

For this option, CCADB manual entry data would specify a URL for
the properly formatted repository page, for example
https://repository.example.com/repo/mailCPS/history/index3.html
(the example.com CA business uses the filenames index.html and
index2.html for previous systematic schemes, all the page forms
are probably generated from the same backend data).

On 03/05/2019 17:36, Ben Wilson wrote:
> I'm against having to continually update the exact URL of the CP and CPS in the CCADB. It's pretty easy to find the current CP and CPS from a legal repository. Plus, if we point to an exact one in the CCADB, it might not be the one that is applicable to a given certificate that was issued prior to the most current CPS. In other words, you should look at when the certificate was issued and then figure out which CPS is applicable.
>
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Andrew Ayer via dev-security-policy
> Sent: Thursday, May 2, 2019 8:16 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Unretrievable CPS documents listed in CCADB
>
> On Thu, 2 May 2019 18:53:39 -0700 (PDT)
> Corey Bonnell via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> As an aside, I noticed that several URLs listed in CCADB are “Legal
>> Repository” web page URLs that contain a list of many CP/CPS
>> documents. My recommendation is to slightly amend CCADB Policy to
>> require CAs to provide URLs to the specific document in question
>> rather than a general “Legal Repository” page, where it is left up to
>> the reader to decide which hyperlink on the page is the correct
>> document.
>
> +1. It's often a real hassle to find the CP/CPS for a CA. Linking
> directly to the document would help a lot.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Wayne Thayer]

On Fri, May 3, 2019 at 8:36 AM Ben Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I'm against having to continually update the exact URL of the CP and CPS
> in the CCADB.

A relatively simple solution to this problem is to create a "permanent
link" to the current version of these docs (e.g.
https://digicert.com/repository/current_cp.pdf), then modify or redirect
the document that the link returns each time the document is updated as
part of the publishing process. Under this scheme, the CA should never need
to worry about updating CCADB.

> It's pretty easy to find the current CP and CPS from a legal repository.

But not as easy as getting it from a CCADB report, especially when the
repository page doesn't clearly map a policy to a CA certificate.

Plus, if we point to an exact one in the CCADB, it might not be the one
> that is applicable to a given certificate that was issued prior to the most
> current CPS. In other words, you should look at when the certificate was
> issued and then figure out which CPS is applicable.
>
>

I'm almost always looking for the current policy rather than trying to
identify the version applicable to a specific certificate.

[Ben Wilson]

That approach could work.

From: Wayne Thayer <wth...@mozilla.com>
Sent: Friday, May 3, 2019 1:19 PM
To: Ben Wilson <ben.w...@digicert.com>
Cc: Andrew Ayer <ag...@andrewayer.name>; Corey Bonnell <cbon...@outlook.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Unretrievable CPS documents listed in CCADB

On Fri, May 3, 2019 at 8:36 AM Ben Wilson via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:

I'm against having to continually update the exact URL of the CP and CPS in the CCADB.





A relatively simple solution to this problem is to create a "permanent link" to the current version of these docs (e.g. https://digicert.com/repository/current_cp.pdf), then modify or redirect the document that the link returns each time the document is updated as part of the publishing process. Under this scheme, the CA should never need to worry about updating CCADB.



It's pretty easy to find the current CP and CPS from a legal repository.





But not as easy as getting it from a CCADB report, especially when the repository page doesn't clearly map a policy to a CA certificate.



Plus, if we point to an exact one in the CCADB, it might not be the one that is applicable to a given certificate that was issued prior to the most current CPS. In other words, you should look at when the certificate was issued and then figure out which CPS is applicable.



I'm almost always looking for the current policy rather than trying to identify the version applicable to a specific certificate.



-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org <mailto:dev-security-...@lists.mozilla.org> > On Behalf Of Andrew Ayer via dev-security-policy
Sent: Thursday, May 2, 2019 8:16 PM
To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Unretrievable CPS documents listed in CCADB

On Thu, 2 May 2019 18:53:39 -0700 (PDT)
Corey Bonnell via dev-security-policy

[Man Ho]

I could be wrong, but some browsers (IE/Chrome) seems to cache
downloaded PDF file and display the cache file if the filename is the
same. If it's true, end user may be actually reading an outdated PDF file.

- Man Ho

[Matt Palmer]

On Sat, May 04, 2019 at 11:11:43AM +0000, Man Ho via dev-security-policy wrote:
> I could be wrong, but some browsers (IE/Chrome) seems to cache
> downloaded PDF file and display the cache file if the filename is the
> same. If it's true, end user may be actually reading an outdated PDF file.

If a browser is caching content retrieved from the target of a 307 Temporary
Redirect under the initial URI which issued the redirect, I'm *pretty* sure
that's a bug, and should be reported as such.

- Matt