[Cryptography Team] Debugging SSL on Linux

Robert Withers reefedjib at yahoo.com
Wed Mar 21 01:22:09 UTC 2007


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/cryptography/attachments/20070320/427f4fd7/attachment.htm


More information about the Cryptography mailing list