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
