Format of EC SubjectPublicKeyInfo I am unable to account for an extra 0x00 byte in an EC SubjectPublicKeyInfo structure.

&gt; openssl asn1parse -i -in ecpub.pem -dump
0:d=0  hl=2 l=  89 cons: SEQUENCE          
2:d=1  hl=2 l=  19 cons:  SEQUENCE          
4:d=2  hl=2 l=   7 prim:   OBJECT            :id-ecPublicKey
13:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
23:d=1  hl=2 l=  66 prim:  BIT STRING        
  0000 - 00 04 d0 ee 64 61 7b 90-48 a2 a9 5f b5 a3 da 67   ....da{.H.._...g
  0010 - 53 56 91 e0 cf 5b b8 85-3e 05 0c b9 e6 95 c3 8d   SV...[..&gt;.......
  0020 - 26 ab d7 ee 47 94 38 61-1e cd 07 e6 90 0b 3d 4a   &amp;...G.8a......=J
  0030 - 6a df c5 d5 9f f3 11 91-53 00 ff 0e 91 93 49 44   j.......S.....ID
  0040 - 4c 58                                             LX


In the BIT STRING representing the public key in octet form, what is the 0x00 byte that precedes the 0x04 byte (which I was expecting to be the first byte)? Without the mysterious 0x00 byte, the public key comes out to 65 bytes and the entire structure lines up with the SEC1 specification.
The BIT STRING value starts with a single byte that indicates the number of bits that are not used. Bit strings may be of any size and they may therefore not be a multiple of 8. So they start with the number of bits that should be skipped at the end. In your case, it tells the user that all bits of the last byte 58 (01011000 in bits) are part of the value. 

Most of the time the BIT STRING encodes a byte array anyway, so it will generally be set to 00 instead of one of the other 7 possibilities.

The first bit is the leftmost bit, and the final bit is the rightmost bit. But that's only of importance if the order of bits is of consequence. In this case the BIT STRING contains the uncompressed EC point $W$ so it is not important.

You can find this, and more in the Layman's guide to ASN.1 by  Burton S. Kaliski Jr. section 5.4 "BIT STRING", and of course the standard documents ITU-T X.680 and X.690 (both payware, so I won't link).