On 2010-07-30 20:53 PDT, Wan-Teh Chang wrote: > On Fri, Jul 30, 2010 at 11:29 AM, Nelson B Bolyard <nel...@bolyard.me> wrote: >> I think you're right. I filed >> https://bugzilla.mozilla.org/show_bug.cgi?id=583308 >> with a patch to fix at least one problem. > > I ran Hanno's test program in a debugger.
Why didn't I think of that? :-/ > I saw the problem that Hanno reported, that the ASN.1 encoder calls > SEC_ASN1GetSubTemplate one time too many. > > The first SEC_ASN1GetSubTemplate call is caused by the SEC_ASN1_OPTIONAL > flag. > > The second SEC_ASN1GetSubTemplate call, which causes the assertion > failure, is caused by the SEC_ASN1_EXPLICIT flag. > > Using this MXR query for SEC_ASN1_POINTER, you can see that no ASN.1 > templates use SEC_ASN1_POINTER with SEC_ASN1_EXPLICIT: > http://mxr.mozilla.org/security/search?string=SEC_ASN1_POINTER > > So it's not surprising the ASN.1 encoder may have problems with the > SEC_ASN1_POINTER | SEC_ASN1_EXPLICIT combination. > > So one solution is to not use a pointer field in the structure. But I > understand you want the field to be a pointer because it is optional. > Then I found that NSS deals with such an "optional field with an explicit > tag" by using a "PointerTo" template. So THAT'S WHY NSS has those PointerTo templates. Thank you, Wan-Teh, for solving an old old mystery! So, I conclude from this that we should make one of two changes, either: a) change both the ASN.1 encoders and decoders to ASSERT that no template contains both OPTIONAL and EXPLICIT, or else b) change the ASN.1 encoder to make that combination work (it already works in the decoder, I believe). I will update bug 583308 with this info. > Here is an example in mozilla/security/nss/lib/certhigh/ocsp.c: > http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/ocsp.c#1188 > > Here is Hanno's code modified to use a PointerTo template: > > SEC_ASN1_MKSUB(SECOID_AlgorithmIDTemplate) > > const SEC_ASN1Template MY_PointerToAlgorithmIDTemplate[] = { > { SEC_ASN1_POINTER, 0, SEC_ASN1_SUB(SECOID_AlgorithmIDTemplate) } > }; > > const SEC_ASN1Template MY_RSAPSSParamsTemplate[] = > { > { SEC_ASN1_SEQUENCE, 0, NULL, sizeof(SECKEYRSAPSSParams) }, > { SEC_ASN1_OPTIONAL | SEC_ASN1_CONSTRUCTED | SEC_ASN1_EXPLICIT | > SEC_ASN1_XTRN | SEC_ASN1_CONTEXT_SPECIFIC | 0, > offsetof(SECKEYRSAPSSParams, hashAlg), > MY_PointerToAlgorithmIDTemplate }, > { 0 } > }; > > SECStatus > PSSU_EncodeDER(SECItem *dest, CK_RSA_PKCS_PSS_PARAMS *in) > { > SECKEYRSAPSSParams *pss_params; > PRArenaPool *arena; > SECItem *ret; > unsigned int i; > > arena = PORT_NewArena(DER_DEFAULT_CHUNKSIZE); > pss_params = PORT_ZAlloc(sizeof(*pss_params)); > pss_params->hashAlg = PORT_ZAlloc(sizeof(SECAlgorithmID)); > > SECOID_SetAlgorithmID(arena, pss_params->hashAlg, SEC_OID_SHA256, NULL); > > ret = SEC_ASN1EncodeItem(arena, NULL, pss_params,MY_RSAPSSParamsTemplate); > > PORT_FreeArena(arena, PR_FALSE); > return SECSuccess; > } > > Wan-Teh -- /Nelson Bolyard <b> </b> 12345678901234567890123456789012345678901234567890123456789012345678901234567890 00000000011111111112222222222333333333344444444445555555555666666666677777777778 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
