Since we're talking about bare public keys / not verifying certificates again, a brief reminder:
https://tools.ietf.org/html/draft-barnes-dane-uks-00 On Wed, Aug 22, 2018 at 12:49 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > Viktor Dukhovni <ietf-d...@dukhovni.org> writes: > > >Some DANE users have reached similar conclusions, though a bit of ASN.1 > >parsing is still required to "seek" to the SPKI, which is not at a fixed > >offset in the certificate. > > It's actually much simpler than that because you've got a nice unique byte > string, the OID, in front of the key. My code jumps 64 bytes in and then > scans from there looking for the byte string corresponding to SEQUENCE { > RSA > OID, NULL }. What follows is the public key, you skip the wrapper bytes > and > grab the two integer values that follow. > > > 41 32: SEQUENCE { > > 43 13: UTCTime 27/07/2014 14:59:59 GMT > > 58 15: GeneralizedTime 27/11/3013 14:59:59 GMT > > : } > > Yeah, seen those sorts of things too, my code has special-case handling to > clip validTo at 32-bit INT_MAX - 1 if it sees long lifetimes (getting > pedantic, it's actually 2036 since some embedded libraries have problems > with > time_t values too close to INT_MAX). > > >It does not stricly comply with RFC5280, which forbids empty RDN sequences > >for the issuer field, but this does not seem to be a problem in practice. > > Yup. If all you're doing is a string search for the RSA OID, no-one cares > what else is or isn't present. > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
