[Cryptography Team] Debugging SSL on Linux

[Robert Withers]

Ron,

This is all very complicated and some careful thought needs to be  
given on how to proceed.  The good news is that by turning off the  
decoding of CertificateExtensions, everything works as it stands.  To  
take the next steps and really implement ASN.1, we need to handle  
Explicit and Implicit tagging of user defined Types.

I was glad you picked a point and restarted the conversation.  What  
follows is more of the mess...

On Mar 21, 2007, at 5:04 PM, Ron Teitelbaum wrote:
> I need to digest all this and read up some more.  I’m still suck on  
> the bit 6.  Doesn’t the 1 in bit 6 mean that we have a constructed  
> value?  Which I translate to mean an object with ivars.
Bit 6 being constructed does not mean that it is an object with  
ivars.  BER encoding allows primitive types to be constructed.  DER  
encoding prevents this, but there are other Explicit types which can  
be constructed that are not objects with ivars.

I played around with VW this afternoon an the way they model a user  
defined type is shown as an example which defines the Type  
#TBSCertificate:

	( x509Module SEQUENCE: #TBSCertificate )
		addElement: #version type: #Version tag: 0 tagging: #explicit  
default: 0;
		addElement: #serialNumber type: #CertificateSerialNumber;
		addElement: #signature type: #AlgorithmIdentifier;
		addElement: #issuer type: #Name;
		addElement: #validity type: #Validity;
		addElement: #subject type: #Name;
		addElement: #subjectPublicKeyInfo type: #SubjectPublicKeyInfo;
		addOptionalElement: #issuerUniqueID type: #UniqueIdentifier tag: 1  
tagging: #implicit;
		addOptionalElement: #subjectUniqueID type: #UniqueIdentifier tag: 2  
tagging: #implicit;
		addOptionalElement: #extensions type: #Extensions tag: 3 tagging:  
#explicit;
		mapping: TBSCertificate;
		retainEncoding: true.

The DERStream then uses this type to unpack the values and map them  
to TBSCertificate.  Notice the 3 OptionaElements.  2 are Implicit and  
1 is Explicit.  This has to do with how the tagging shakes out.

The first Implicit type hides the type tag of the underlying  
UniqueIdentifier with the Implicit [1], so there is no tag explicitly  
for the UniqueIdentifier.  The Type definition knows this, which we  
re missing in our implementation.
	{10000001} [length octet] [UniqueIdentifier value]

The Explicit type does not hide the underlying type tag, and it  
doesn't have to be sequence.
	{10100011} [length octet] [{00110000} [length octet] [Extension  
values]]



In the original case I brought up, there is an Implicit constructed  
Sequence, which was tagged:
	{10100000} [length octet] [Sequence values]

>
> Primitive means single data element  (i.e. String)
>
> Constructed means multiples (i.e. SomeObject).
This is not necessarily true.  Your original posting pointed it out:
>>  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 can be "simple string types, ..., types derived from anything by  
explicit tagging".  In BER encoding, you can encode an IA5String with  
the constructed type:
	36 13
	   16 05 74 65 73 74 31
	   16 01 40
	   16 07 72 73 61 2e 63 6f 6d
	constructed encoding: "test1" + "@" + "rsa.com"
In DER encoding it has to be primitive, however.

>  Explicit means field name comes from ANS definition.
>
> Implicit means field name comes from data?
Explicit means it wraps a full Triplet [Explicit tag] [length1]  
[Underlying tag] [length2] [value].  Implicit retags the underlying  
Triplet [Implicit tag] [length] [value]

Both come from the type definition and that is what is needed to know  
how to decode/encode these structures.
>  Although I’m not sure.  Like I said I need to read up some more.
I got a lot of this from the doc you are using "A Layman's Guide to a  
Subset of ASN.1,. BER, and DER"
>  The definition parser is really not that complicated.  It is  
> almost done, I was hoping to add pragmas onto objects to allow  
> reading and writing to asn from the metadata on the ivars.  This  
> would tie the definition to the object model.  Problem is having  
> enough time to finish it.
I personally don't like pragmas.  I prefer to use a Type-MetaType  
pattern and have the Type instance separate from the associated  
class.  Whether this Type (the MetaType) comes from a Smalltalk  
construction, like the VW example, or comes out of an ASN.1  
Definition Parser is a wash.  The goal is the execution environment  
of the decoding will be a stream with a Type to interpret the tags  
and values.  Unless I am missing something.  In honesty, I don't know  
what you have done.

Lot's to chew on,
Robert

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