On Mar 21, 2007, at 10:15 AM, Ron Teitelbaum wrote:
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?)
I am trying to find out the intersection of Explicit/Implicit and Primitive/Constructed. I think what I am learning is that the Primitive/Constructed is represented in the tag of a Triplet, but the Explicit/Implicit is a property of the Type Module defining user types. We don't have any representation of that, since we are wrapping it all in an ASN1ExplicitContextValue.
I am still wrapping both Primitive and Constructed, but I took you advice and allowed Constructed types to have more than one value - i.e. an Implicit Sequence
We really need to do what you were working on it seems with your ASN1DefinitionModel. We need to be able to provide the Type definition to the parser, which is just the #fromAsnDer: method, and allow the BER to be mapped to user classes. Big job.
Rob
Rob,
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.
I read your other emails and I think I'm catching onto the issues. I'm not sure I understand what combinations are possible.
Primitive means single data element (i.e. String)
Constructed means multiples (i.e. SomeObject).
Explicit means field name comes from ANS definition.
Implicit means field name comes from data?
Although I'm not sure. Like I said I need to read up some more.
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.
Ron
_____
From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Wednesday, March 21, 2007 4:27 PM To: Ron@USMedRec.com Subject: Re: [Cryptography Team] Debugging SSL on Linux
On Mar 21, 2007, at 10:15 AM, Ron Teitelbaum wrote:
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?)
I am trying to find out the intersection of Explicit/Implicit and Primitive/Constructed. I think what I am learning is that the Primitive/Constructed is represented in the tag of a Triplet, but the Explicit/Implicit is a property of the Type Module defining user types. We don't have any representation of that, since we are wrapping it all in an ASN1ExplicitContextValue.
I am still wrapping both Primitive and Constructed, but I took you advice and allowed Constructed types to have more than one value - i.e. an Implicit Sequence
We really need to do what you were working on it seems with your ASN1DefinitionModel. We need to be able to provide the Type definition to the parser, which is just the #fromAsnDer: method, and allow the BER to be mapped to user classes. Big job.
Rob
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
cryptography@lists.squeakfoundation.org
-
Robert Withers -
Ron Teitelbaum