On Thu, Mar 21, 2019 at 01:00:14PM +0000, Salz, Rich via openssl-users wrote:
> > This software however is 7 years old, we’re not in a position to drop everything and rewrite it.
>
> Then don't upgrade? If it's for a CA you don't need TLS 1.3 for example.
>
> Or take the existing OpenSSL code that works and jam it into the current release.
Perhaps the OP is not an end-user, but rather maintains these modules
for a user community, in which case "don't upgrade" is not generally
an option. In any case, it seems a bit premature to close the
conversation.
While the original decision to use incomplete (and thus invalid)
CSRs, is unfortunate, and not OpenSSL's fault, we can still continue
to discuss meaningful options. On the DER padding front, the minimal
working suffix is 7 bytes:
30 03 -- Length 3 sequence
06 01 00 -- OBJECT ID: 0.0
03 01 00 -- empty BIT STRING
One then also prepends a prefix (typically 4 bytes):
30 82 xx xx -- a sequence of 256 to 65535 bytes
30 81 xx -- a sequence of 128 to 255 bytes
30 xx -- a sequence of up to 127 bytes
The "xx" length is the DER length of the CRI + 7 bytes for the
suffix.
On the OpenSSL side, having found that we emit dubious encodings
of structures with an (unspecified) null OID element, I am considering
whether it would make sense to encode them as a zero-length (invalid,
but faithful) ASN.1 OBJECT:
06 00
*and* decode these back to a zero length NID_undef object. While
these are likely to not interoperate with many other ASN.1 decoder
implementations, just interoperating with the same version of OpenSSL
would make it possible to encode/decode partially initialized
structures in which some "objects" are as yet unspecified.
The reason I'm considering changes is that it now appears that the
original commmit that stopped encoding single element OIDs, is not
fully baked. Just skipping required components of structures is
not a good outcome.
--
Viktor.
