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? >> 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 ... >> 2) The EncryptedKey is encoded as the now deprecated EncryptedValue >> structure. Is there a plan to encode the value with EnvelopedData >> structure any time soon ? No. Contributed patches are usually welcome. :) >> 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'd guess that the attempt to wrap the private key with the CA's public key failed, resulting in a zero length value being encoded. Have you a CA server with which I can test this? >> FYI: If CRMF request contains cert request for a signing >> key pair the ProofOfPossession is valid (a correct instance of >> POPOSigningKey) and is correctly verified by our decoder. >> >> Does anyone know if these issues have been addressed in FF 3.5 and if >> not, will they be addressed in the next releases of FF ? No work has been done on CRMF in a LONG time. >> Many thanks in advance, >> Nikolai Koustov. I look forward to further discussion of this. :) Regards, /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto