Hi Nelson, On Jul 18, 2:48 am, Nelson B Bolyard <nel...@bolyard.me> wrote: > On 2009-07-17 17:40 PDT, Daniel Veditz wrote: > > > Moving discussion to mozilla.dev.tech.crypto, but do go ahead and file > > bugs. I doubt 3.5 behaves any differently than 3.0 (you did mean 3.0.10, > > right? If you're using Firefox 2 please stop). > > nk wrote: > >> Hi all, > >> I am researching the window.crypto.generatedCRMFRequest() function > >> available on FireFox (I am using FF 2.0.10). > > I agree with Dan. If you're using 2.0.x, please don't. It's not supported > (not by us). Did you mean 3.0.10? Yeah, of course I meant 3.0.10. BTW, version 3 is awesome - keep it going, lads. I had some niggling issues with the earlier 3.0 revisions, but it is much more stable now.
> > >> Now, if requested keys are for signing - everything looks good. > >> But if requested keys are for key exchange (e.g. "rsa-ex"), the > >> generated CRMF request structure has a number of issues. > > >> Here are the issues I am facing: > >> 1) A PKIArchiveOptions control is included (http://www.ietf.org/rfc/ > >> rfc4211.txt, section 6.4). > > We don't claim conformance to RFC 4211. We claim conformance to RFC 2511. > Not that it makes much difference. > > >> The EncryptedKey structure in it is encoded > >> as a SEQUENCE while it actually is a CHOICE. Our CRMF decoder is > >> throwing as soon as it sees this structure. Shall I raise a bug ? > > No. As you should know, there is no explicit encoding for a choice. > A choice is encoded as the encoding of the selected one of the alternative > values. In this case, the chosen alternative is an EncryptedValue, which > is a SEQUENCE, so it is encoded as a sequence. The module uses IMPLICIT > TAGS, and I suspect that you're expecting this sequence to be implicitly > tagged rather than explicitly tagged. It is explicitly tagged because of > the requirement in X.680-0207 section 28.4 Note 1, which says: > > > NOTE 1 – The rules governing specification of implicit tagging or > > explicit tagging for replacement "TaggedType"s are provided by 30.6. > > Automatic tagging is always implicit tagging unless the "Type" is an > > untagged choice type or an untagged open type notation, or an untagged > > "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3), in which > > case it is explicit tagging. > > Also, X.680-0207 section 30.6 says: > > > 30.6 The tagging construction specifies explicit tagging if any of the > > following holds: > > a) the "Tag EXPLICIT Type" alternative is used; > > b) the "Tag Type" alternative is used and the value of "TagDefault" for > > the module is either EXPLICIT TAGS or is empty; > > c) the "Tag Type" alternative is used and the value of "TagDefault" for > > the module is IMPLICIT TAGS or AUTOMATIC TAGS, but the type defined by > > "Type" is an untagged choice type, an untagged open type, or an untagged > > "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3). > > > The tagging construction specifies implicit tagging otherwise. > > So, the PKIArchiveOptions should be encoded as something like: > A0 nn 30 nn ... > Thanks a lot - what you say makes a lot of sense. I can see what you mean about explicit vs implicit tagging and have now modified our decoder to lookup the context of the ASN1Object to see if the value was tagged explicitly or implicitly and rely on the context to implicitly decode to a particular ASN1 type. > >> 3) Finally, the ProofOfPossession structure looks broken in this > >> scenario as what we see is: A2 05 80 03 00 03 00, which does not seem > >> to relate to any of the permitted options desrcibed in RFC 4211, > >> section 4. > > That does seem strange. We have a [2] explicitly encoding a [0] which > is an implicit bit string with no unused bits, apparently encapsulating > another bit string of length zero. :-/ I have now modified our decoder to correctly recognize POPOPrivKey encoded as thisMessage, i.e. [0]. That BitString contains "03 00". Is it expected to be that way ? Regards, Nikolai. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
