348
edits
Apps/WebApplicationReceipt/GenerationService: Difference between revisions
Jump to navigation
Jump to search
Apps/WebApplicationReceipt/GenerationService (view source)
Revision as of 21:44, 29 March 2012
, 29 March 2012→Comments / Concerns / Clarification Needed
| Line 106: | Line 106: | ||
== Comments / Concerns / Clarification Needed == | == Comments / Concerns / Clarification Needed == | ||
* [mcoates - 2012-03-28] We refer to sites e.g. "Within a given site". Do we mean data centers? [mhanson 2012-03-29] yes. or whatever unit of operational-stability-and-granularity makes sense. | * [mcoates - 2012-03-28] We refer to sites e.g. "Within a given site". Do we mean data centers? | ||
* [mcoates - 2012-03-28] Need to | ** [mhanson 2012-03-29] yes. or whatever unit of operational-stability-and-granularity makes sense. | ||
* [mcoates - 2012-03-28] Need to specify that the receipt verfication service hosted by mozilla is only accessible via HTTPS | |||
* [mcoates - 2012-03-28] review Bug needed - review implementation to ensure daily private keys are correctly destroyed | * [mcoates - 2012-03-28] review Bug needed - review implementation to ensure daily private keys are correctly destroyed | ||
* [mcoates - 2012-03-28] Threat #2 - More discussion is needed here to understand this requested control "Infrasec will correlate the signing activity log with actual requests from the Marketplace. " | * [mcoates - 2012-03-28] Threat #2 - More discussion is needed here to understand this requested control "Infrasec will correlate the signing activity log with actual requests from the Marketplace. " | ||
* [clouserw - 2012-03-29] Am I correct in my understanding that the HSM is used to generate a key once a day which lives on a .well-known distribution point. From there the receipt signing nodes pick up on the new key and sign receipts with it? So the HSMs aren't actually being used to sign the receipts, just to hold the private key securely? | * [clouserw - 2012-03-29] Am I correct in my understanding that the HSM is used to generate a key once a day which lives on a .well-known distribution point. From there the receipt signing nodes pick up on the new key and sign receipts with it? So the HSMs aren't actually being used to sign the receipts, just to hold the private key securely? | ||
* [clouserw - 2012-03-29] In order to use the /.well-known/ prefix we'd technically have to register it with the standards folks (after debate). Obviously we can do what we want, but we'd be out of spec at that point. [mhanson 2012-03-29] added clarification about using RFC 6415 too | ** [mhanson - 2012-03-29] That is correct; that is the most-secure pattern, according to badida and bwarner. | ||
* [clouserw - 2012-03-29] The receipt reissuance moves the authority of a valid receipt from the original certificates to the AMO database. I don't know a way around that, but it's worth noting. [mhanson 2012-03-29] I think the AMO database has always been the ground truth since it's the place that knows about refunds and chargebacks. Don't think it changes the picture in the big scheme. | |||
* [clouserw - 2012-03-29] The receipt validation and reissuance checks are complicated. We should definitely provide server side code examples for developers trying to implement that. [mhanson 2012-03-29] Most recent draft attempts to simplify by eliminating cert revocation from validation. | * [clouserw - 2012-03-29] In order to use the /.well-known/ prefix we'd technically have to register it with the standards folks (after debate). Obviously we can do what we want, but we'd be out of spec at that point. | ||
* [clouserw - 2012-03-29] I haven't seen plans for a way to query for receipts by User ID. I'm happy to skip that until it's shown we need it. [mhanson 2012-03-29] Good, a service to do that would have weird/bad privacy characteristics. | ** [mhanson 2012-03-29] added clarification about using RFC 6415 too. If we can find an existing REL to use the XRD, great. | ||
* [clouserw - 2012-03-29] In Appendix B you ask if the public keys and the revoked keys should be in the same file, but in "Software Components" you say that the public keys are on an intranet-only URL. In "System Overview" you mention that the developer's servers can retrieve the list of revoked keys but they won't have access to an intranet-only URL. [mhanson 2012-03-29] the private keys are intranet only - the public keys are "delivered carefully to the advertising point" - e.g. the public website | |||
* [clouserw - 2012-03-29] The receipt reissuance moves the authority of a valid receipt from the original certificates to the AMO database. I don't know a way around that, but it's worth noting. | |||
** [mhanson 2012-03-29] I think the AMO database has always been the ground truth since it's the place that knows about refunds and chargebacks. Don't think it changes the picture in the big scheme. | |||
* [clouserw - 2012-03-29] The receipt validation and reissuance checks are complicated. We should definitely provide server side code examples for developers trying to implement that. | |||
** [mhanson 2012-03-29] Most recent draft attempts to simplify by eliminating cert revocation from validation. | |||
* [clouserw - 2012-03-29] I haven't seen plans for a way to query for receipts by User ID. I'm happy to skip that until it's shown we need it. | |||
** [mhanson 2012-03-29] Good, a service to do that would have weird/bad privacy characteristics. | |||
* [clouserw - 2012-03-29] In Appendix B you ask if the public keys and the revoked keys should be in the same file, but in "Software Components" you say that the public keys are on an intranet-only URL. In "System Overview" you mention that the developer's servers can retrieve the list of revoked keys but they won't have access to an intranet-only URL. | |||
** [mhanson 2012-03-29] the private keys are intranet only - the public keys are "delivered carefully to the advertising point" - e.g. the public website | |||
== Action Items == | == Action Items == | ||