Hello everyone,
Can anyone help debugging SSL on Linux?
This is from Norbert:
I'm using it on linux with squeak vm 3.9-8 #5 Tue Oct 10 11:56:09 PDT 2006 gcc 4.0.3 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux ubuntu 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-8/*.so and a stock 3.9 7067 image. I tried using a fresh copy of the image but the errors stay the same errors.
I tried using the url that Norbert gave and it worked fine on Windows.
'https://home.selfish.org https://home.selfish.org/ ' asUrl retrieveContents.
Could someone try this on Linux and see if they can help provide info as to what is going wrong. I suspect that the client hello is causing the server to disconnect. Maybe an Endian issue?
Thanks,
Ron Teitelbaum Squeak Cryptography Team Leader
Ron and Norbert,
I found that SSL failed to establish a connection on the Mac, and I suspect the same is actually true on Windows, on close inspection. The resulting MIMEDocument has an error when evaluating the example:
'https://home.selfish.org' asUrl retrieveContents.
I debugged into the SSLSocket and found where the ProtocolCap was getting killed. This occurred when processing the SSLCertificateMsg, with a certificate chain of 2 certificates. The new code I added to verify certificates is having a problem verifying certificate 1 with certificate 2.
Digging a little further showed that there are 3 problems, the 2nd and 3rd hidden by the 1st.
The 1st problem is the comparison if cert1's issuer with cert2's subject. One part of these X509Names is a Pkcs9EmailAddress, which is wrapping a ASN1IA5String. This class (ASN1IA5String) is missing an #= operation, and so they are claiming they are not equal. I fixed this.
The 2nd and 3rd problems are ASN1 encoding/decoding problems.
The 2nd problem is an issue with tag 12 being encoded as 19, the default for a String. the source bytes encoded with this code | bytes | bytes := #(160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray. (ASN1Value fromAsnDer: bytes readStream) encodeAsnDer.
encode as #(160 18 19 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)
check the third byte to see the problem. Since the TBSCertificate are reencoded for signature checking, the ASN1 hierarchy must be able to reencode precisely. So I added several classes for different types of strings (ASN1PrintableString, ASN1UniversalString, and ASN1BMPString) and updated the tag table to use them. This solves this problem, but there are still holes in the ASN1 tag framework.
The 3rd problem is an ASN1 decoding problem with an ASN1ExplicitContextValue class, that is embedded in a CertificateExtension. Here is the ExplicitContextValue part, which seems to be malformed:
| bytes ext | bytes := #(160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray. ext := (ASN1Value fromAsnDer: bytes readStream). ext encodeAsnDer
resulting in: a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5)
Notice the 2nd byte. Now this being embedded means that the part that dropped off is actualy captured in the certExtension, and when he certExtension encdes itself, here is the fragment that it encodes:
a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)
The original bytes gave a length of 30, which captured 2 values and I didn't think a ExplicitContextValue could do that. The encoded bytes have a length of 10 which is just the first element. When it decodes, instead of grabbing the bytes specified by length it just decodes the next ASN1Value, the first chunk. So here is how it breaks down:
<{160} [30] ( <{6} [8] (43 6 1 5 5 7 8 5)> <{160} [18] ( <{12} [16] (104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)> )> )>
Now, either an ExplicitContextValue can have 2 values like this, and we need to change some code, or this is malformed. Please advise if we can change ExplicitContextValue to handle this.
If it is malformed, then because we are re-encoding the ASN1 bytes to do signatures, and since I added the Certificate Extensions, this is now breaking. Either we need to save the original bytes to do signatures with, and avoid re-encoding, or else this correctly fails. Saving the original bytes of ASN1 is a major rewrite.
Sorry I couldn't get this site working for you right away, but we will need to resolve this issue in the design, first.
Robert
On Mar 20, 2007, at 11:01 AM, Ron Teitelbaum wrote:
Hello everyone,
Can anyone help debugging SSL on Linux?
This is from Norbert:
I'm using it on linux with squeak vm 3.9-8 #5 Tue Oct 10 11:56:09 PDT 2006 gcc 4.0.3 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux ubuntu 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux default plugin location: /usr/local/lib/ squeak/3.9-8/*.so and a stock 3.9 7067 image. I tried using a fresh copy of the image but the errors stay the same errors.
I tried using the url that Norbert gave and it worked fine on Windows.
'https://home.selfish.org' asUrl retrieveContents.
Could someone try this on Linux and see if they can help provide info as to what is going wrong. I suspect that the client hello is causing the server to disconnect. Maybe an Endian issue?
Thanks,
Ron Teitelbaum Squeak Cryptography Team Leader
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Hey Rob,
I'll look more into the asn issue but this doesn't explain why it works on my machine.
I was able to connect and retrieve data just fine, I just checked again with:
ANS1.26
Core.23
SSL.109
X509.32
I'll try your new code but first I'll verify the extension data and see if I can tell why it is parsing correctly on my machine. I can't get to it till tomorrow.
Thanks for looking at it!
Ron
_____
From: Robert Withers [mailto:reefedjib@yahoo.com] Sent: Tuesday, March 20, 2007 4:43 PM To: Ron@USMedRec.com; Cryptography Team Development List Cc: 'Norbert Hartl' Subject: Re: [Cryptography Team] Debugging SSL on Linux
Ron and Norbert,
I found that SSL failed to establish a connection on the Mac, and I suspect the same is actually true on Windows, on close inspection. The resulting MIMEDocument has an error when evaluating the example:
' https://home.selfish.org/ https://home.selfish.org' asUrl retrieveContents.
I debugged into the SSLSocket and found where the ProtocolCap was getting killed. This occurred when processing the SSLCertificateMsg, with a certificate chain of 2 certificates. The new code I added to verify certificates is having a problem verifying certificate 1 with certificate 2.
Digging a little further showed that there are 3 problems, the 2nd and 3rd hidden by the 1st.
The 1st problem is the comparison if cert1's issuer with cert2's subject. One part of these X509Names is a Pkcs9EmailAddress, which is wrapping a ASN1IA5String. This class (ASN1IA5String) is missing an #= operation, and so they are claiming they are not equal. I fixed this.
The 2nd and 3rd problems are ASN1 encoding/decoding problems.
The 2nd problem is an issue with tag 12 being encoded as 19, the default for a String.
the source bytes encoded with this code
| bytes |
bytes := #(160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray.
(ASN1Value fromAsnDer: bytes readStream) encodeAsnDer.
encode as
#(160 18 19 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)
check the third byte to see the problem. Since the TBSCertificate are reencoded for signature checking, the ASN1 hierarchy must be able to reencode precisely. So I added several classes for different types of strings (ASN1PrintableString, ASN1UniversalString, and ASN1BMPString) and updated the tag table to use them. This solves this problem, but there are still holes in the ASN1 tag framework.
The 3rd problem is an ASN1 decoding problem with an ASN1ExplicitContextValue class, that is embedded in a CertificateExtension. Here is the ExplicitContextValue part, which seems to be malformed:
| bytes ext |
bytes := #(160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray.
ext := (ASN1Value fromAsnDer: bytes readStream).
ext encodeAsnDer
resulting in:
a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5)
Notice the 2nd byte. Now this being embedded means that the part that dropped off is actualy captured in the certExtension, and when he certExtension encdes itself, here is the fragment that it encodes:
a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)
The original bytes gave a length of 30, which captured 2 values and I didn't think a ExplicitContextValue could do that. The encoded bytes have a length of 10 which is just the first element. When it decodes, instead of grabbing the bytes specified by length it just decodes the next ASN1Value, the first chunk. So here is how it breaks down:
<{160} [30] (
<{6} [8] (43 6 1 5 5 7 8 5)>
<{160} [18] (
<{12} [16] (104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)>
)>
)>
Now, either an ExplicitContextValue can have 2 values like this, and we need to change some code, or this is malformed. Please advise if we can change ExplicitContextValue to handle this.
If it is malformed, then because we are re-encoding the ASN1 bytes to do signatures, and since I added the Certificate Extensions, this is now breaking. Either we need to save the original bytes to do signatures with, and avoid re-encoding, or else this correctly fails. Saving the original bytes of ASN1 is a major rewrite.
Sorry I couldn't get this site working for you right away, but we will need to resolve this issue in the design, first.
Robert
On Mar 20, 2007, at 11:01 AM, Ron Teitelbaum wrote:
Hello everyone,
Can anyone help debugging SSL on Linux?
This is from Norbert:
I'm using it on linux with squeak vm 3.9-8 #5 Tue Oct 10 11:56:09 PDT 2006 gcc 4.0.3 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux ubuntu 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-8/*.so and a stock 3.9 7067 image. I tried using a fresh copy of the image but the errors stay the same errors.
I tried using the url that Norbert gave and it worked fine on Windows.
'https://home.selfish.org https://home.selfish.org/ ' asUrl retrieveContents.
Could someone try this on Linux and see if they can help provide info as to what is going wrong. I suspect that the client hello is causing the server to disconnect. Maybe an Endian issue?
Thanks,
Ron Teitelbaum Squeak Cryptography Team Leader
_______________________________________________
Cryptography mailing list
Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Rob,
I took a quick look and you are right it is nasty.
30 32 (50):
. 82 10 (16):
. 686F6D652E73656C666973682E6F7267
. A0 1E (30):
. . 06 08 (8):
. . 2B06010505070805
. . A0 12 (18):
. . . 0C 10 (16):
. . . 686F6D652E73656C666973682E6F7267
So it's an explicit cv holding onto an explicit cv and another value. Notice the problem goes back even further and happens twice for this extension. So assuming that this problem matches with the asn rules then can we say that we encode, for size only, the content of an explicit contenxt value as a collection when the element size doesn't match the first size.
So encode is
checkValueSize against next item and set value to collection if necessary, then decode until size is reached.
And decode is
If value is collection then encode items in collection and then set size from encoded values.
I still want to check the docs but I'm guessing that I just missed this possibility.
Since the ECV is just a wrapper for the tag number, (and your isPrimitive flag), would this cause any other problems?
Ron
_____
From: Robert Withers [mailto:reefedjib@yahoo.com] Sent: Tuesday, March 20, 2007 4:43 PM To: Ron@USMedRec.com; Cryptography Team Development List Cc: 'Norbert Hartl' Subject: Re: [Cryptography Team] Debugging SSL on Linux
Ron and Norbert,
I found that SSL failed to establish a connection on the Mac, and I suspect the same is actually true on Windows, on close inspection. The resulting MIMEDocument has an error when evaluating the example:
' https://home.selfish.org/ https://home.selfish.org' asUrl retrieveContents.
I debugged into the SSLSocket and found where the ProtocolCap was getting killed. This occurred when processing the SSLCertificateMsg, with a certificate chain of 2 certificates. The new code I added to verify certificates is having a problem verifying certificate 1 with certificate 2.
Digging a little further showed that there are 3 problems, the 2nd and 3rd hidden by the 1st.
The 1st problem is the comparison if cert1's issuer with cert2's subject. One part of these X509Names is a Pkcs9EmailAddress, which is wrapping a ASN1IA5String. This class (ASN1IA5String) is missing an #= operation, and so they are claiming they are not equal. I fixed this.
The 2nd and 3rd problems are ASN1 encoding/decoding problems.
The 2nd problem is an issue with tag 12 being encoded as 19, the default for a String.
the source bytes encoded with this code
| bytes |
bytes := #(160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray.
(ASN1Value fromAsnDer: bytes readStream) encodeAsnDer.
encode as
#(160 18 19 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)
check the third byte to see the problem. Since the TBSCertificate are reencoded for signature checking, the ASN1 hierarchy must be able to reencode precisely. So I added several classes for different types of strings (ASN1PrintableString, ASN1UniversalString, and ASN1BMPString) and updated the tag table to use them. This solves this problem, but there are still holes in the ASN1 tag framework.
The 3rd problem is an ASN1 decoding problem with an ASN1ExplicitContextValue class, that is embedded in a CertificateExtension. Here is the ExplicitContextValue part, which seems to be malformed:
| bytes ext |
bytes := #(160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray.
ext := (ASN1Value fromAsnDer: bytes readStream).
ext encodeAsnDer
resulting in:
a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5)
Notice the 2nd byte. Now this being embedded means that the part that dropped off is actualy captured in the certExtension, and when he certExtension encdes itself, here is the fragment that it encodes:
a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)
The original bytes gave a length of 30, which captured 2 values and I didn't think a ExplicitContextValue could do that. The encoded bytes have a length of 10 which is just the first element. When it decodes, instead of grabbing the bytes specified by length it just decodes the next ASN1Value, the first chunk. So here is how it breaks down:
<{160} [30] (
<{6} [8] (43 6 1 5 5 7 8 5)>
<{160} [18] (
<{12} [16] (104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)>
)>
)>
Now, either an ExplicitContextValue can have 2 values like this, and we need to change some code, or this is malformed. Please advise if we can change ExplicitContextValue to handle this.
If it is malformed, then because we are re-encoding the ASN1 bytes to do signatures, and since I added the Certificate Extensions, this is now breaking. Either we need to save the original bytes to do signatures with, and avoid re-encoding, or else this correctly fails. Saving the original bytes of ASN1 is a major rewrite.
Sorry I couldn't get this site working for you right away, but we will need to resolve this issue in the design, first.
Robert
On Mar 20, 2007, at 11:01 AM, Ron Teitelbaum wrote:
Hello everyone,
Can anyone help debugging SSL on Linux?
This is from Norbert:
I'm using it on linux with squeak vm 3.9-8 #5 Tue Oct 10 11:56:09 PDT 2006 gcc 4.0.3 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux ubuntu 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-8/*.so and a stock 3.9 7067 image. I tried using a fresh copy of the image but the errors stay the same errors.
I tried using the url that Norbert gave and it worked fine on Windows.
'https://home.selfish.org https://home.selfish.org/ ' asUrl retrieveContents.
Could someone try this on Linux and see if they can help provide info as to what is going wrong. I suspect that the client hello is causing the server to disconnect. Maybe an Endian issue?
Thanks,
Ron Teitelbaum Squeak Cryptography Team Leader
_______________________________________________
Cryptography mailing list
Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Ron,
I just want to reiterate that by not preserving the original bytes when decoding, we are forced to re-encode to check signatures. With that comment out of the way...
First, I turned off CertificateExtension decoding and republished, so the latest code should now work. I couldn't get it to work...
Second, this is long in the tooth...
I am referring to the ASN1 book by Olivier Dubuisson, which you had referred me to at one point so I think you have access to this pdf.
Per Figure 18.2 on page 396, we are using the ASN1ExplicitContextValue to wrap APPLICATION {01cttttt}, Context- specific {10cttttt} and PRIVATE {11cttttt} values - tags 6 and 7. They can be Primitive (Implicit) or Constructed (Explicit) - tag 5. This specific example is using Explicit Context-specific [0] (see page 409, section 18.2.16 Tagged value, where the value of the Explicit triplet is itself one triplet).
Now, this section just named refers to page 216, which is the chapter on Constructed values. I just scanned it and it seems necessary to define structures as a SEQUENCE, with no "implicit" structures - i.e. they don't seem to define a Context-specific type that can hold more than one Triplet without embedding it in a SEQUENCE.
So, here is the type definition for an Extension:
Extension ::= SEQUENCE { extnId EXTENSION.&id ({ExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } -- contains a DER encoding of a value of type
and the problem we are having is by trying to DER decode the extnValue field. Here is the full data for that field, both raw and parsed with hex values:
#(48 50 130 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103 160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray
SEQUENCE = T(30) L(32) V( Implicit [2] = T(82) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67) Explicit [0] = T(A0) L(1E) V( OID = T(06) L(08) V(2B 06 01 05 05 07 08 05) Explicit [0] = T(A0) L(12) V( String = T(0C) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67))))
The outer is a SEQUENCE and is ok. Inside, at the value of the first Explicit [0] Triplet, it is not a SEQUENCE, but it has 2 Triplets inside of it. Looking at its Length (1E), it thinks it should be holding both Triplets.
The code is only grabbing the first Triplet when decoding an Explicit [0], and then the outer Sequence is decoding the second inner Triplet, so I actually get:
Sequence ( Implicit [2] Explicit [0] (OID) Explicit [0] (String))
instead of:
Sequence ( Implicit [2] Explicit [0] ( OID Explicit [0]))
the corresponding length is messed up when I re-encode it.
That's funny, as we agree. I'll post to the ASN1 list...
later, Rob
On Mar 20, 2007, at 4:30 PM, Ron Teitelbaum wrote:
So it’s an explicit cv holding onto an explicit cv and another value. Notice the problem goes back even further and happens twice for this extension. So assuming that this problem matches with the asn rules then can we say that we encode, for size only, the content of an explicit contenxt value as a collection when the element size doesn’t match the first size.
So encode is
checkValueSize against next item and set value to
collection if necessary, then decode until size is reached.
And decode is
If value is collection then encode items in collection
and then set size from encoded values.
I still want to check the docs but I’m guessing that I just missed this possibility.
Since the ECV is just a wrapper for the tag number, (and your isPrimitive flag), would this cause any other problems?
Rob,
I think what we have is a
3.2 Constructed, definite-length method
This method applies to simple string types, structured types, types derived
simple string types and structured types by implicit tagging, and types derived
from anything by explicit tagging. It requires that the length of the value be
known in advance. The parts of the BER encoding are as follows:
Identifier octets. As described in Section 3.1, except that bit 6 has value "1,"
indicating that the encoding is constructed.
The value 160 (1 in bit 6) should be considered a Constructed, Definite-length field. I'm still researching it but it would seem to me that this is how you define a user object within a value. Instead of having a primitive data type within an explicit context value you have a constructed data type (in our world an object with ivars).
I'm still reading but I think that we may be able to replace 160 with ASN1ExplicitContextValueConstructed that has a definite length and holds the values in a sequence. Do you have the actual ANS.1 definition for this extension? I'd be interested if it says that it's explicit constructed.
Ron
_____
From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Tuesday, March 20, 2007 9:22 PM To: Ron@USMedRec.com Cc: 'Cryptography Team Development List'; 'Norbert Hartl' Subject: Re: [Cryptography Team] Debugging SSL on Linux
Ron,
I just want to reiterate that by not preserving the original bytes when decoding, we are forced to re-encode to check signatures. With that comment out of the way...
First, I turned off CertificateExtension decoding and republished, so the latest code should now work. I couldn't get it to work...
Second, this is long in the tooth...
I am referring to the ASN1 book by Olivier Dubuisson, which you had referred me to at one point so I think you have access to this pdf.
Per Figure 18.2 on page 396, we are using the ASN1ExplicitContextValue to wrap APPLICATION {01cttttt}, Context-specific {10cttttt} and PRIVATE {11cttttt} values - tags 6 and 7. They can be Primitive (Implicit) or Constructed (Explicit) - tag 5. This specific example is using Explicit Context-specific [0] (see page 409, section 18.2.16 Tagged value, where the value of the Explicit triplet is itself one triplet).
Now, this section just named refers to page 216, which is the chapter on Constructed values. I just scanned it and it seems necessary to define structures as a SEQUENCE, with no "implicit" structures - i.e. they don't seem to define a Context-specific type that can hold more than one Triplet without embedding it in a SEQUENCE.
So, here is the type definition for an Extension:
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
-- contains a DER encoding of a value of type
and the problem we are having is by trying to DER decode the extnValue field. Here is the full data for that field, both raw and parsed with hex values:
#(48 50 130 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103 160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray
SEQUENCE = T(30) L(32) V(
Implicit [2] = T(82) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67)
Explicit [0] = T(A0) L(1E) V(
OID = T(06) L(08) V(2B 06 01 05 05 07 08 05)
Explicit [0] = T(A0) L(12) V(
String = T(0C) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67))))
The outer is a SEQUENCE and is ok. Inside, at the value of the first Explicit [0] Triplet, it is not a SEQUENCE, but it has 2 Triplets inside of it. Looking at its Length (1E), it thinks it should be holding both Triplets.
The code is only grabbing the first Triplet when decoding an Explicit [0], and then the outer Sequence is decoding the second inner Triplet, so I actually get:
Sequence (
Implicit [2]
Explicit [0] (OID)
Explicit [0] (String))
instead of:
Sequence (
Implicit [2]
Explicit [0] (
OID
Explicit [0]))
the corresponding length is messed up when I re-encode it.
That's funny, as we agree. I'll post to the ASN1 list...
later,
Rob
On Mar 20, 2007, at 4:30 PM, Ron Teitelbaum wrote:
So it's an explicit cv holding onto an explicit cv and another value. Notice the problem goes back even further and happens twice for this extension. So assuming that this problem matches with the asn rules then can we say that we encode, for size only, the content of an explicit contenxt value as a collection when the element size doesn't match the first size.
So encode is
checkValueSize against next item and set value to collection if necessary, then decode until size is reached.
And decode is
If value is collection then encode items in collection and then set size from encoded values.
I still want to check the docs but I'm guessing that I just missed this possibility.
Since the ECV is just a wrapper for the tag number, (and your isPrimitive flag), would this cause any other problems?
Rob,
http://www.columbia.edu/~ariel/ssleay/layman.html
6.2.4 RelativeDistinguishedName
The three RelativeDistinguishedName values are SET OF values, so their DER encodings follow the constructed, definite-length method:
31 0b 30 09 ... 55 53
31 1d 30 1b ... 6f 6e
31 14 30 12 ... 20 31
The identifier octets follow the low-tag-number form, since the tag for SET OF, 17 (decimal), is between 0 and 30. Bits 8 and 7 have value "0" since SET OF is in the universal class Bit 6 has value "1" since the encoding is constructed. The lengths octets follow the short form, and the contents octets are the DER encodings of the respective AttributeValueAssertion values, since there is only one value in each set.
What do you think? Does changing 160 to ANS1ExplicitContextValueConstructed fix things? I suppose that we could also, if it makes sense, extend the ECV functionality to include handling multiple values if bit 6 = 1 and eliminate some duplication of code (i.e. isPrimitive, but does isPrimitive make sense for ECVC?)
Ron
_____
From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Ron Teitelbaum Sent: Wednesday, March 21, 2007 12:59 PM To: 'Cryptography Team Development List'; 'Robert Withers' Subject: RE: [Cryptography Team] Debugging SSL on Linux
Rob,
I think what we have is a
3.2 Constructed, definite-length method
This method applies to simple string types, structured types, types derived
simple string types and structured types by implicit tagging, and types derived
from anything by explicit tagging. It requires that the length of the value be
known in advance. The parts of the BER encoding are as follows:
Identifier octets. As described in Section 3.1, except that bit 6 has value "1,"
indicating that the encoding is constructed.
The value 160 (1 in bit 6) should be considered a Constructed, Definite-length field. I'm still researching it but it would seem to me that this is how you define a user object within a value. Instead of having a primitive data type within an explicit context value you have a constructed data type (in our world an object with ivars).
I'm still reading but I think that we may be able to replace 160 with ASN1ExplicitContextValueConstructed that has a definite length and holds the values in a sequence. Do you have the actual ANS.1 definition for this extension? I'd be interested if it says that it's explicit constructed.
Ron
_____
From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Tuesday, March 20, 2007 9:22 PM To: Ron@USMedRec.com Cc: 'Cryptography Team Development List'; 'Norbert Hartl' Subject: Re: [Cryptography Team] Debugging SSL on Linux
Ron,
I just want to reiterate that by not preserving the original bytes when decoding, we are forced to re-encode to check signatures. With that comment out of the way...
First, I turned off CertificateExtension decoding and republished, so the latest code should now work. I couldn't get it to work...
Second, this is long in the tooth...
I am referring to the ASN1 book by Olivier Dubuisson, which you had referred me to at one point so I think you have access to this pdf.
Per Figure 18.2 on page 396, we are using the ASN1ExplicitContextValue to wrap APPLICATION {01cttttt}, Context-specific {10cttttt} and PRIVATE {11cttttt} values - tags 6 and 7. They can be Primitive (Implicit) or Constructed (Explicit) - tag 5. This specific example is using Explicit Context-specific [0] (see page 409, section 18.2.16 Tagged value, where the value of the Explicit triplet is itself one triplet).
Now, this section just named refers to page 216, which is the chapter on Constructed values. I just scanned it and it seems necessary to define structures as a SEQUENCE, with no "implicit" structures - i.e. they don't seem to define a Context-specific type that can hold more than one Triplet without embedding it in a SEQUENCE.
So, here is the type definition for an Extension:
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
-- contains a DER encoding of a value of type
and the problem we are having is by trying to DER decode the extnValue field. Here is the full data for that field, both raw and parsed with hex values:
#(48 50 130 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103 160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray
SEQUENCE = T(30) L(32) V(
Implicit [2] = T(82) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67)
Explicit [0] = T(A0) L(1E) V(
OID = T(06) L(08) V(2B 06 01 05 05 07 08 05)
Explicit [0] = T(A0) L(12) V(
String = T(0C) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67))))
The outer is a SEQUENCE and is ok. Inside, at the value of the first Explicit [0] Triplet, it is not a SEQUENCE, but it has 2 Triplets inside of it. Looking at its Length (1E), it thinks it should be holding both Triplets.
The code is only grabbing the first Triplet when decoding an Explicit [0], and then the outer Sequence is decoding the second inner Triplet, so I actually get:
Sequence (
Implicit [2]
Explicit [0] (OID)
Explicit [0] (String))
instead of:
Sequence (
Implicit [2]
Explicit [0] (
OID
Explicit [0]))
the corresponding length is messed up when I re-encode it.
That's funny, as we agree. I'll post to the ASN1 list...
later,
Rob
On Mar 20, 2007, at 4:30 PM, Ron Teitelbaum wrote:
So it's an explicit cv holding onto an explicit cv and another value. Notice the problem goes back even further and happens twice for this extension. So assuming that this problem matches with the asn rules then can we say that we encode, for size only, the content of an explicit contenxt value as a collection when the element size doesn't match the first size.
So encode is
checkValueSize against next item and set value to collection if necessary, then decode until size is reached.
And decode is
If value is collection then encode items in collection and then set size from encoded values.
I still want to check the docs but I'm guessing that I just missed this possibility.
Since the ECV is just a wrapper for the tag number, (and your isPrimitive flag), would this cause any other problems?
On Mar 21, 2007, at 9:59 AM, Ron Teitelbaum wrote:
Rob,
I think what we have is a
3.2 Constructed, definite-length method This method applies to simple string types, structured types, types derived simple string types and structured types by implicit tagging, and types derived from anything by explicit tagging. It requires that the length of the value be known in advance. The parts of the BER encoding are as follows: Identifier octets. As described in Section 3.1, except that bit 6 has value "1," indicating that the encoding is constructed.
It turns out to be Implicit, which means you don't have the value encoded with explicit tags. The definition specifies the type, in this case a Sequence.
The value 160 (1 in bit 6) should be considered a Constructed, Definite-length field. I’m still researching it but it would seem to me that this is how you define a user object within a value. Instead of having a primitive data type within an explicit context value you have a constructed data type (in our world an object with ivars).
It is constructed because it is not a simple "primitive" type.
I’m still reading but I think that we may be able to replace 160 with ASN1ExplicitContextValueConstructed that has a definite length and holds the values in a sequence. Do you have the actual ANS.1 definition for this extension? I’d be interested if it says that it’s explicit constructed.
It's Implicit constructed. Here is the definition:
-- subject alternative name extension OID and syntax
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE { otherName [0] AnotherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER }
-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
AnotherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE { nameAssigner [0] DirectoryString OPTIONAL, partyName [1] DirectoryString }
and my bytes specify:
Sequence { dNSName [2] IA5String, otherName [0] AnotherName}
where AnotherName is an Implicit sequence.
Rob
cryptography@lists.squeakfoundation.org