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: This relates to including an object identifier (OID) into signature structures as output of the bccsp. This would of course need to be accommodated in software and hsm bccsp version.    Information provided by Tamas Visegrady:    Example structs, with blue highlights for object Ids: signerInfo [so an EC signature, incl. who signed + with which alg]  -------------------------------    0 204: SEQUENCE {    3   1:   INTEGER 3    6  32:   [0]         :     0B 06 70 18 51 AF DD 31 3A D8 CD 24 C6 EA 18 32       -- SKI [subj key info] of signer                                                                     --   -> pubkey(SKI) -> ...         :     A0 24 83 B0 60 B0 8D 59 A5 13 13 B9 B8 C7 CD 2E   40  11:   SEQUENCE {   42   9:     OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3)    -- [hash is separately noted]         :     }   53  10:   SEQUENCE {   55   8:     OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)         :     }   65 139:   OCTET STRING, encapsulates {   68 136:     SEQUENCE {   71  66:       INTEGER         :         00 24 52 19 83 BF 15 21 88 EB 61 E3 E2 54 7A C7   -- R         :         60 EF 53 E7 3B 75 88 F3 AB 31 37 35 51 DA 31 13  ....  139  66:       INTEGER         :         01 1D F6 96 21 3F FA C3 04 FA 7A 9F 70 F2 0E A8   -- S         :         CA 46 3D 31 2B 6C 11 A9 69 2D B6 26 75 1B 79 A0  ...         :       }         :     }         :   }  -------------------------------  digestInfo:                     -- so just a self-documenting enclosure around a hash    0  77: SEQUENCE {    2   9:   OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3)   13  64:   OCTET STRING         :     4F 28 5D 0C 0C C7 72 86 D8 73 17 98 B7 AA E2 63         :     9E 28 27 0D 41 66 F4 0D 76 9C BB DC A5 23 07 14         :     D8 48 48 3D 36 4E 2F 39 FE 6C B9 08 3C 15 22 9B         :     39 A3 36 15 EB C6 D5 76 05 F7 C4 3F 69 06 73 9D         :   }  ---------------  00000000: 304d 0609 6086 4801 6503 0402 0304 404f  0M..`.H.e.....@O    --- OID  00000010: 285d 0c0c c772 86d8 7317 98b7 aae2 639e  (]...r..s.....c.  00000020: 2827 0d41 66f4 0d76 9cbb dca5 2307 14d8  ('.Af..v....#...  00000030: 4848 3d36 4e2f 39fe 6cb9 083c 1522 9b39  HH=6N/9.l..<.".9  00000040: a336 15eb c6d5 7605 f7c4 3f69 0673 9d    .6....v...?i.s.  -------------------------------  so these structs are all self-describing.  hw-Miniboot relies on this unambigous decoding to store a hash in the early stages [when it can not yet sign data]; we simply document that in those cases, a digestInfo can be where a signerInfo is expected.    OIDs for digests, incl. digestInfo's:  -----------  319         "2.16.840.1.101.3.4.2.1         id-sha256               ALGID",  320         "2.16.840.1.101.3.4.2.2         id-sha384               ALGID",  321         "2.16.840.1.101.3.4.2.3         id-sha512               ALGID",   -- ex. struct above  322         "2.16.840.1.101.3.4.2.4         id-sha224               ALGID",  323         "2.16.840.1.101.3.4.2.5         id-sha512-224           ALGID",  324         "2.16.840.1.101.3.4.2.6         id-sha512-256           ALGID",  325         "2.16.840.1.101.3.4.2.7         id-sha3-224             ALGID",  326         "2.16.840.1.101.3.4.2.8         id-sha3-256             ALGID",  327         "2.16.840.1.101.3.4.2.9         id-sha3-384             ALGID",  328         "2.16.840.1.101.3.4.2.10        id-sha3-512             ALGID",  329         "2.16.840.1.101.3.4.2.11        id-sha3-shake128        ALGID",  330         "2.16.840.1.101.3.4.2.12        id-sha3-shake256        ALGID",  -----------  this list above should cover any hash function we can think of.
Answer: 1545672.0