Re: CRMF encoding issues with window.crypto.generatedCRMFRequest()
On 2009-07-22 06:09 PDT, nk wrote:
Is there any way I can reproduce what you're seeing?
I would probably require me to be able to access your CA server,
and perhaps also to trust your root cert for the test.
There is no CA server involved at this point. All I am doing is
supplying a Base-64 encoded certificate to encrypt the private key
with. Here is the value:
[Snipped]
Then I pass it to generateCRMFRequest() like so:
var crmfObject = window.crypto.generateCRMFRequest ('CN=Test
CRMF', null, null, bigString
'',
1024, null, 'rsa-ex');
the request is then placed on a form and sent to a servlet where I
retrieve the CRMF from the HTTP request and decode it.
Can you generate a CRMF request yourself with my cert and analyze the
POP section of the generated CRMF request ?
Please email me a copy of the entire web page with the above javascript
in it and whatever else it has. I may be able to trace through it.
Or perhaps you could decode the CRMF request I get and see if you
observe the same ?
[snipped] Alas, NSS's utility programs do not include any tools to decode
and print CRMF requests and CMMF responses.
Please note that the ArchiveControl structure is generated ok and
seems to contain the generated private key (I have not tried to
actually decrypt it) so I would rule out that the generation or
encryption part fails.
Thanks,
Nikolai.
--
12345678901234567890123456789012345678901234567890123456789012345678901234567890
0112233445566778
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CRMF encoding issues with window.crypto.generatedCRMFRequest()
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 ?
I think it is not expected to be that way. As I wrote before:
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.
Is there any way I can reproduce what you're seeing?
I would probably require me to be able to access your CA server,
and perhaps also to trust your root cert for the test.
There is no CA server involved at this point. All I am doing is
supplying a Base-64 encoded certificate to encrypt the private key
with. Here is the value:
MIIDEDCCAfigAwIBAgIBATANBgkqhkiG9w0BAQUFADAoMQswCQYDVQQGEwJVUzEMMAoGA1UEChMD
NTMxMQswCQYDVQQDEwJjYTAeFw0wNzExMTMxNTAxMjJaFw0xMDExMTMxNTAxMjJaMCgxCzAJBgNV
BAYTAlVTMQwwCgYDVQQKEwM1MzExCzAJBgNVBAMTAmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAsRCC0uVqV7PWAAlVg0aBKIKExrn
+hSyq531H144D6TkIN5EHJ5sfgeF3o6VMqUsX
usfQNofIPpz6bUhSFCEIdbd5zeOdn5AqEVstY18uzE6vxWidmxe6qkMrPi51HW7oTPOreC5auTGC
Jfnjk8hBnXtIx8Dt2vRgHH1laKYyeRLczN7tkcVc29D7FSxPW
+vrU6IhDnKbfKoh5uzTJ7TrDY0Q
y6+5qfohd5k1gy4CQ7W/MRq6tsOks/x4+4iEJEhN/
RtsziW4qfhv81GOMyed8njgIXBGHmLGVTDI
umWCfpMerHA
+UIz5a6SSeRV79lID7mYQMhrXDDNzJQ6zk1BtmQIDAQABo0UwQzASBgNVHRMBAf8E
CDAGAQH/AgEDMA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUUsoh2TFbcOWauSNO6GFBSE/
9MEcw
DQYJKoZIhvcNAQEFBQADggEBAKH4M6J+EueLrQYUdtdXn29XSi
+tEB0e7eT5zeKuWEuuxKnD8Itb
cLpRD8x7+2Z3FTVbk76wdkqp9IjcJUGDicNWdRLBG49hd0wtZoU6t1+UKUhIFcOEyh9C1p4WkW81
qZUD5QtceYlC2vxhJDWKBgRNbfKOfBGI69ZMgKtDVEYpY0/VDZClQUPlk8mCTssdFxI/
IJPxj4xr
QotX8g6Q7h/WhzEOGaVPU6s16KYH+L4Ko6CQXVo6G0QSi2q8DU7F6uwsO
+WpvwEuqxUNAzgGioMA
ChZX2ZWQDHHmRNOn74mMu9OB2d/qUPT7VBVtvns5gh9tQB2Ecw2/TharyCMIs5k=
Then I pass it to generateCRMFRequest() like so:
var crmfObject = window.crypto.generateCRMFRequest ('CN=Test
CRMF', null, null,
'MIIDEDCCAfigAwIBAgIBATANBgkqhkiG9w0BAQUFADAoMQswCQYDVQQGEwJVUzEMMAoGA1UEChMD'+
'NTMxMQswCQYDVQQDEwJjYTAeFw0wNzExMTMxNTAxMjJaFw0xMDExMTMxNTAxMjJaMCgxCzAJBgNV'+
'BAYTAlVTMQwwCgYDVQQKEwM1MzExCzAJBgNVBAMTAmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A'+
'MIIBCgKCAQEAsRCC0uVqV7PWAAlVg0aBKIKExrn
+hSyq531H144D6TkIN5EHJ5sfgeF3o6VMqUsX'+
'usfQNofIPpz6bUhSFCEIdbd5zeOdn5AqEVstY18uzE6vxWidmxe6qkMrPi51HW7oTPOreC5auTGC'+
'Jfnjk8hBnXtIx8Dt2vRgHH1laKYyeRLczN7tkcVc29D7FSxPW
+vrU6IhDnKbfKoh5uzTJ7TrDY0Q'+
'y6+5qfohd5k1gy4CQ7W/MRq6tsOks/x4+4iEJEhN/
RtsziW4qfhv81GOMyed8njgIXBGHmLGVTDI'+
'umWCfpMerHA
+UIz5a6SSeRV79lID7mYQMhrXDDNzJQ6zk1BtmQIDAQABo0UwQzASBgNVHRMBAf8E'+
'CDAGAQH/AgEDMA4GA1UdDwEB/
wQEAwIBxjAdBgNVHQ4EFgQUUsoh2TFbcOWauSNO6GFBSE/9MEcw'+
'DQYJKoZIhvcNAQEFBQADggEBAKH4M6J+EueLrQYUdtdXn29XSi
+tEB0e7eT5zeKuWEuuxKnD8Itb'+
'cLpRD8x7+2Z3FTVbk76wdkqp9IjcJUGDicNWdRLBG49hd0wtZoU6t1+UKUhIFcOEyh9C1p4WkW81'+
'qZUD5QtceYlC2vxhJDWKBgRNbfKOfBGI69ZMgKtDVEYpY0/VDZClQUPlk8mCTssdFxI/
IJPxj4xr'+
'QotX8g6Q7h/WhzEOGaVPU6s16KYH+L4Ko6CQXVo6G0QSi2q8DU7F6uwsO
+WpvwEuqxUNAzgGioMA'+
'ChZX2ZWQDHHmRNOn74mMu9OB2d/qUPT7VBVtvns5gh9tQB2Ecw2/TharyCMIs5k=',
'',
1024, null, 'rsa-ex');
the request is then placed on a form and sent to a servlet where I
retrieve the CRMF from the HTTP request and decode it.
Can you generate a CRMF request yourself with my cert and analyze the
POP section of the generated CRMF request ?
Or perhaps you could decode the CRMF request I get and see if you
observe the same ?
MIIEwTCCBL0wggSyAgUA/
wsb3DCBz4ABAqUWMBQxEjAQBgNVBAMTCVRlc3QgQ1JNRqaBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApQ1KFor5oiRRahGQX6394NiO5BPv6jashk4dnMGq9KjDPbfu
YgRZ5QqKT3lR7azuNxbXxhMPWEjswbsBfNoOfZjdnxBqH16monF18PVJzg1Fy8dpW4j/
MbEn+gSz
7SLcd4VS5TxPRrfnCB2GhVNkhbN7CE49XuKszJ7YOEIU/scCAwEAAakQMA4GA1UdDwEB/
wQEAwIF
IDCCA9UwggOzBgkrBgEFBQcFAQSgggOkMIIDoKEUBggqhkiG9w0DBwQIoMhxKyreKFyCggEBAJWE
p0AeSv3wovVziTmUlh9zMWxu9XKFqiGn9dmxSAHpLNQRmAI5wBadEOiV
+i5hjomPJ78lXspv4MsH
zBzvZTY8VZDvftC6/2ikwJvpdYflhT/R6uKTK9Zh
+MQNeZCfFHtxpyXDq9BbS7mzxmRtXpgdAK6k
9mWxG64V5I6dlfpcLDeZ4ZjeOQT3kR7oe4n4oCP3IuHQPsEvtL8EhhsQB04vbgCFBNC4Uz1+lwJO
AJeI4D9YdErtyqUo1MqBtwpQKL6DKJNrM9XsAYHmZfDNGCOb
+7Cpeo2rBr8BbQ0B5LEzuu56SibX
rvAaKerXUAj9MPE66xqurzfaAoE8ovrxk4QDggKBAHQFGYEH6sveKTqzR/v2WOfOM3tBzv/
yDCEs
CXYiE6VQIVHQFcyTNEleRT5zM6PIrUszFpG5f3xjcdLGq6DWUdlqbFbcLE0OluqVG/
6AWks3clqH
mg0V1SVIOkXqJxsbMGkzag2/Du0/yxdDL1vPb9NeDysw7qP4cL1d5Rnd
+5zmb39HXVFqZHdlRuXd
uNcb8Gf5J/qmfceKCeIbPh9quuQdUYKiagT7s1WPI38TuJXQQWNBAQMuV/
jmZ0dFKX7JZYmbrf5/
8ROdd+M05+kCfx4GyS2jEtCGvq/EbdTirx2y5BdbeN7Mmt2SY/WhO023Y0/z5micpg
+OrakJNLQc
U7N3SfiDmm1FAJ0LshkdgNEs6GVD/GCVC6/DvmFGgQgsVbjnfhUqwMz
+5y5FaRbaW76oqO0w6qeN
47Ef+YoZ7gfY/Jd3MVQaM6f9QVyUH5a5DddCgpN9f6qLhVqb86OBO8CIak+oKL
+wfRam52ZNDnB/
gGzYFamrjryh
+ejW6dR1eo5XRnKx5PstWeeR0VNbj3NzoeTiWZHQSnEPzCFOOYBoV94mEZ3rj3O7
Re: CRMF encoding issues with window.crypto.generatedCRMFRequest()
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 TaggedTypes 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
Re: CRMF encoding issues with window.crypto.generatedCRMFRequest()
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). 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). 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 ? 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 ? 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. 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 ? Many thanks in advance, Nikolai Koustov. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CRMF encoding issues with window.crypto.generatedCRMFRequest()
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 TaggedTypes 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
