give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently, when the peer runs with TLS enabled, the authentication works as follows:   * The chaincode service running on the peer uses the peer's organizational TLS certificate, signed by the peer's root TLS CA.   * The peer generates a self signed CA certificate upon startup   * It injects the chaincode shim container with a TLS client certificate that is signed by the CA certificate it generated.   * In order for the chaincode shim to authenticate the peer's TLS certificate, when the chaincode image is compiled (and only then), the peer injects it with the root CA certificate it has in its file system, which is the root TLS CA that signed its own TLS server certificate.         There are a few problems with this setup:   # It is asymmetrical - we use different CAs - an organizational one to authenticate in 1 direction, and a self generated one to authenticate in the other direction.   # When the peer launches the chaincode shim, it passes it via a commandline argument, the endpoint of the peer it should connect to, and this endpoint is derived using the values from peer.chaincodeListenAddress or of missing, from a value computed from the peer's endpoint which is set via peer.endpoint or if missing, via auto-detection of the container's ip address.   In many cases, customers such as in FAB-6937 and many others in rocket-chat / stackoverflow don't configure their YAML files properly and this results in the peer's address passed to the chaincode container being an ip address instead of the peer's hostname. When this happens, the chaincode shim refuses to connect to the peer because the certificate of the peer has only the DNS name of the peer, and doesn't container the IP subject alternative name in the certificate.   # Now, an immediate limitation that stems from this, is that a customer can actually never use just ip addresses for its peer when running with TLS, unless it specifically creates custom TLS certificates with the ip address.   # Another related problem is that when the customer replaces root CA certificates, it now needs to manually remove all the chaincode container images - a management overhead.     * I think we should strive to build a system that reduces configuration mistakes as much as possible when we can.   * I also think that it's more secure to have the chaincode shim connect to the peer using credentials that are kept in the peer's memory and are made by it, and not such that the organizational CA can issue - as the chaincode belongs to the peer and not to the organization.         *There are 2 solutions, the first one solves just the mis-configuration problem, and the 2nd solves all problems.*         To solve (only) the mis-configuration problem we can do something simple:   * Include in the chaincode shim's image, the TLS certificate (without the private key, of course) of the peer, and have the chaincode shim look into the certificate to identify what DNS or IP SANs it has, and use this to connect to the peer when running with TLS. *Note: This change involves changing the chaincode shim's code in all platforms*              To solve all the problems I listed here I propose the following:   # Have the peer's self signed CA certificate that is generated upon startup, generate a TLS server certificate for the peer (make a TLS certificate and sign it) and use it only for the chaincode listener (which is, starting from v1.1 on its own port...).   The certificate will contain either an IP or DNS subject alternative name, according to what the peer is configured (the same endpoint passed to the chaincode shim)   # Upon chaincode container startup, inject the CA certificate along with the shim's client certificate (which is currently injected) and then the shim will use this certificate to authenticate the peer instead of the existing root TLS CA certificate of the peer's organization.     * This change is only in the peer side, and has no effect on any platform chaincode code such as node CC or java CC, etc.   * If it sounds intrusive and complex, it actually isn't so, as we already have the infrastucture to support it, and it is actually pretty small.   Here is an example POC [https://gerrit.hyperledger.org/r/#/c/15427/] that includes everything besides removing the part that bakes the organizational root TLS CA cert into the chaincode image (which won't be needed)    Opinions?    [~<USER> [~<USER> [~<USER> [~<USER> [~<USER> [~adc] [~<USER> [~<USER>"
Answer: 29184.0