On Sun, 3 Jul 2022, Andrew Cagney wrote:
On Thu, 30 Jun 2022 at 17:07, Robert Relyea <rrel...@redhat.com> wrote:before making the second SEC_ASN1EncodeItem() call. I believe this is because that field is encoded using: { SEC_ASN1_BIT_STRING, offsetof(NSSLOWKEYSubjectPublicKeyInfo, subjectPublicKey) }, and SEC_ASN1_BIT_STRING expects the SECItem.len to be in bits not bytes. could the above have the same problem?I think you are right, it could have the same problem.
I was tracing once the ASN.1 code and I found it extremely confiusing that SECItem.len is sometimes in bytes, sometime in bits. If I am not mistaken, functions used to copy such an SECItem will copy 8 times more junk, since BITSTRING data are stored as 8 bits per byte, anyway. I have also noticed that both ASN.1 parsers in the code behave the same way, beefing up SECItem.len times 8. This must be intentional. (Because we do not have any means to store the exact number of bits anywhere?) Should/Shouldn't generic functions be aware of this distiction? Marcin -- You received this message because you are subscribed to the Google Groups "dev-tech-crypto@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-crypto+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/207478r6-8r59-7154-4162-o6r7rponnsoo%40fncre.vasb.
