DER ≠ ASN.1. I've written a handful of BER/DER encoders and decoders without coming near implementing ASN.1. DER is a decent TLV format.
I agree DER is a decent TLV format. However, it seems wrong to require parsing the DER at all just for 1 field that happens to be ASN.1 DER.
-
-
I don't know a lot about the U2F spec, but I agree that it should probably have lengths of its own for convenience and layer separation.
-
That said, isn't it just: it should start with 30 82, then the next two bytes are the length of the rest?
-
No, and that proves my point, I think. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1064670 ….
-
In particular, nothing requires overlong encodings to be rejected. I think that U2F spec could be updated to include that as an extra check.
-
Also, IIUC, attestation certificate can be (arguably, should be) < 256 bytes but not < 127 bytes, i.e. 0x30 0x81 <length byte> is allowed.
-
Yes, I don't know enough about the variety of certs actually seen here. I'm oversimplifying, unaware of general context.
-
If most certs are >= 256 bytes, probably safer for CA to always pad certs to >= 256 bytes, in case someone hard-coded 0x30 0x82 <len> <len>.
-
By my math, a P-256 cert signed with P-256 ECDSA is 235 bytes before you put in subject, issuer, serial number, or extensions.
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.