Confirmed users
502
edits
Apps/WebApplicationReceipt/GenerationService: Difference between revisions
Jump to navigation
Jump to search
m
Apps/WebApplicationReceipt/GenerationService (view source)
Revision as of 21:42, 11 May 2012
, 11 May 2012→Comments / Concerns / Clarification Needed: clarified
Gdestuynder (talk | contribs) |
Gdestuynder (talk | contribs) m (→Comments / Concerns / Clarification Needed: clarified) |
||
| Line 141: | Line 141: | ||
* [andym 2012-04-08] "When a user agent notices that a receipt is approaching its expiry date" I haven't seen anything to suggest that receipts themselves have expiry dates. | * [andym 2012-04-08] "When a user agent notices that a receipt is approaching its expiry date" I haven't seen anything to suggest that receipts themselves have expiry dates. | ||
* [kang 2012-05-11] In Appendix B, the public key which is the root of the trust is stored on a HTTPS webserver. This means if the webserver is compromised, the key can be replaced by any key and the applications will trust it (which may be what you meant by "compromise SSL"). A possible recommendation would be to generate 2 keys in the HSM, lets call them master key and sub key. The master key sign the sub pub key, and we place it on the HTTPS webserver. All apps verify up to the master key, enforcing that, any key must be signed by the HSM master key in order to be trusted (so if someone replace the key on the HTTPS webserver it won't work. he would have to also compromise the HSM) | * [kang 2012-05-11] In Appendix B, the public key which is the root of the trust is stored on a HTTPS webserver. This means if the webserver is compromised, the key can be replaced by any key and the applications will trust it (which may be what you meant by "compromise SSL"). A possible recommendation (note: this is *only* a possible recommendation) would be to generate 2 keys in the HSM, lets call them master key and sub key. The master key sign the sub pub key, and we place it on the HTTPS webserver. All apps verify up to the master key, enforcing that, any key must be signed by the HSM master key in order to be trusted (so if someone replace the key on the HTTPS webserver it won't work. he would have to also compromise the HSM). It also means the trust is established at the first fetch of the master pub key (and that the same threat still exists at this level, but once trusted you would keep it, while the sub key can be replaced. This also means devices such as B2G devices could ship with it, and that also means the master key can be on a different server (so you would have to compromise 2, to compromise the first fetch) | ||
===Security Review Notes=== | ===Security Review Notes=== | ||