[Cryptography Team] Debugging SSL on Linux

Wed Mar 21 17:15:16 UTC 2007

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 at lists.squeakfoundation.org
[mailto:cryptography-bounces at 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 at lists.squeakfoundation.org
[mailto:cryptography-bounces at lists.squeakfoundation.org] On Behalf Of Robert
Withers
Sent: Tuesday, March 20, 2007 9:22 PM
To: Ron at 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/cryptography/attachments/20070321/fadddad8/attachment-0001.htm