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.
-
-
Replying to @BRIAN_____
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.
1 reply 0 retweets 1 like -
Replying to @tdierks @BRIAN_____
That said, isn't it just: it should start with 30 82, then the next two bytes are the length of the rest?
1 reply 0 retweets 0 likes -
Replying to @tdierks
No, and that proves my point, I think. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1064670 ….
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____ @tdierks
In particular, nothing requires overlong encodings to be rejected. I think that U2F spec could be updated to include that as an extra check.
3 replies 0 retweets 1 like -
Replying to @BRIAN_____ @tdierks
Also, IIUC, attestation certificate can be (arguably, should be) < 256 bytes but not < 127 bytes, i.e. 0x30 0x81 <length byte> is allowed.
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____
Yes, I don't know enough about the variety of certs actually seen here. I'm oversimplifying, unaware of general context.
1 reply 0 retweets 0 likes -
Replying to @tdierks
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>.
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____
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.
1 reply 0 retweets 0 likes -
Replying to @tdierks @BRIAN_____
Unless I'm missing context, I'd be surprised to see one under 256 bytes in the wild.
1 reply 0 retweets 0 likes
Here's one that I think may be valid & reasonable that's 251 bytes: https://goo.gl/L2yCos . But usually there will be at least 1 extn.
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.