[Cryptography Team] first cut at CertificateExtensions and
ASN1issues
Robert Withers
reefedjib at yahoo.com
Mon Jan 29 04:04:39 UTC 2007
I published some additional code that solves both of these problems.
We could do what you describe, but I am not sure how many places we
may need to touch to impl it. I kinda like it being a nil object,
since that is the natural object for 5 0.
The problem with encoding the nil incorrectly with
X509AlgorithmIdentifier is really a problem of this object
differentiating an absent parameters field from a NULL parameters
field, both of which are valid. I added an instance variable
#hasParameters, which I set at creation and use in encoding. It
works like a champ.
To solve the custom tags problem, of tags 128 and 130, I added an
instance variable to ASN1ExplicitContextConstructedValue,
#tagIsPrimitive. I set this at construction and use it at encoding
for tag construction. It works too. I setup the right logic in
ASN1Value class>>#typeClassForTag:, so that both primitive and
constructed types use this class. It may be better to have a
separate class for ASN1ExplicitContextPrimitiveValue. What do you
think?
cheers,
Rob
On Jan 28, 2007, at 2:02 PM, Ron Teitelbaum wrote:
> Just a thought, there are a lot of 5 0 coding and I assumed that
> nil was
> good for that, but what if we instead subclass UndefinedObject to
> make an
> ANS1NullObject, then we can put the ANS1NullObject in the parameter
> field if
> it is encoded and nil if it is not. We would then only encode
> ANS1NullObject and skip nils. We could also create a nil asASN1Object
> method for convenience.
>
> I guess the down side is that nils will not automatically encode.
> We could
> set an option on the encoder for encoding nils. What do you think?
>
> I wonder if the asn1 definition helps us here? Is there some sort
> of rule
> about nils we can tap into? Like is the parameter on the
> definition marked
> optional? Are all optional nils dropped during encoding?
>
> I agree with the need to do explicit custom tags. It's all tag
> numbers over
> some value right? I need to look at that again. Can we just wrap
> it to
> save the code, like I did with the custom constructed codes?
>
> Ron
>
>> -----Original Message-----
>> From: Robert Withers [mailto:reefedjib at yahoo.com]
>> Sent: Sunday, January 28, 2007 4:41 PM
>> To: Ron at USMedRec.com; Cryptography Team Development List
>> Subject: Re: [Cryptography Team] first cut at
>> CertificateExtensions and
>> ASN1issues
>>
>> Ron,
>>
>> Here is an example of incorrect re-encoding of an
>> X509AlgorithmIdentifier, due to a NULL parameter field:
>>
>> original bytes: a ByteArray(48 9 6 7 42 134 72 206 56 4 3)
>>
>> X509AlgorithmIdentifier
>> oid: 1.2.840.10040.4.3
>> parameters: nil
>>
>> re-encoded bytes: a ByteArray(48 11 6 7 42 134 72 206 56 4 3 5 0)
>>
>> The X509AlgorithmIdentifier>>#encodeAsnDer method encodes the nil
>> parameter field, whereas the original bytes had a missing parameter
>> field.
>>
>>
>> As for the custom tags, you did the constructed custom tags which
>> seem to work, while I am having trouble with the primitive custom
>> tags. For example your tags start with 2r101xxxxx, while mine start
>> with 2r100xxxxx.
>>
>> Here are some bytes for tag 128: a ByteArray(128 20 22 181 50 27 212
>> 199 243 224 230 142 243 189 210 176 58 238 178 57 24 209)
>> This decodes to a ByteArray (A recent change of mine from
>> ASN1BitString), which would re-encode to tag 4.
>>
>> Here is some bytes for tag 130: a ByteArray(130 1 0)
>> This also decodes to a ByteArray, based on my changes.
>>
>> Perhaps they should also decode to an explicit constructed type.
>>
>> Rob
>>
>> On Jan 28, 2007, at 1:13 PM, Ron Teitelbaum wrote:
>>
>>> Hi Rob,
>>>
>>> Do you have an example of the decoding and encoding difference?
>>> I've been
>>> meaning to take a look at your code but haven't had a chance yet.
>>>
>>> I did the custom tags asn.1 decoding already, and thought they were
>>> working
>>> ok, I should be able to look at it soon. Maybe it would help to
>>> see an
>>> example of the problem.
>>>
>>> Thanks!
>>>
>>> Ron
>>>
>>>> -----Original Message-----
>>>> From: cryptography-bounces at lists.squeakfoundation.org
>>>> [mailto:cryptography-bounces at lists.squeakfoundation.org] On
>>>> Behalf Of
>>>> Robert Withers
>>>> Sent: Sunday, January 28, 2007 4:03 PM
>>>> To: Cryptography Team Development List
>>>> Subject: Re: [Cryptography Team] first cut at
>>>> CertificateExtensions and
>>>> ASN1issues
>>>>
>>>> My code changes broke the certificate validation code, so I rolled
>>>> this back.
>>>>
>>>> The big problem with ASN1 is that the re-encoding of a decoded ASN1
>>>> does not necessarily match the original encoding. There seem to be
>>>> several reasons for this, including an incomplete parsing of
>>>> context-
>>>> specific values and an optional NULL parameter in the
>>>> X509AlgorithmIdentifier. There may be others. It would be nice to
>>>> capture and maintain the original bytes for each node in the
>>>> ASN1Value tree, so we could produce the original bytes on demand.
>>>> However, checking the Certificate signature of the
>>>> TBSCertificate is
>>>> the only use of this that I know of. I believe this is what VW
>>>> does
>>>> and why it does it. Based on he way we incrementally decode ASN1
>>>> from a stream, I don't see how to do it. We would need to
>>>> change the
>>>> way we decode ASN1.
>>>>
>>>> food for thought.
>>>> Rob
>>>>
>>>> On Jan 27, 2007, at 10:59 AM, Robert Withers wrote:
>>>>
>>>>> I made a first cut at parsing the CertificateExtensions. I grab
>>>>> the OID and then I do an ASN1 DER decoding of the value. We have
>>>>> shortcomings in the way we decode the tag for DER/BER encodings.
>>>>> We don't decode multi-byte tags for example.
>>>>>
>>>>> When I was decoding the cert extensions, I ran across several new
>>>>> tags, namely 128 and 130. According to ASN1dubuisson.pdf, these
>>>>> are context-specific, primitive types. When we have the high
>>>>> order
>>>>> bit set, we are masking the low order bits. I changed the mask to
>>>>> mask out the high order bit. This means that my 2 tags decode
>>>>> to a
>>>>> ByteArray, while the ExplicitConstructed type (101xxxxx) still
>>>>> decodes correctly. You may want to review my code in
>>>>> Cryptography-
>>>>> ASN package, specifically the ASN1Value class>>#typeClassForTag:
>>>>>
>>>>> Robert
>>>>> _______________________________________________
>>>>> Cryptography mailing list
>>>>> Cryptography at lists.squeakfoundation.org
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>>>> cryptography
>>>>
>>>> _______________________________________________
>>>> Cryptography mailing list
>>>> Cryptography at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>>> cryptography
>>>
>>>
>>> _______________________________________________
>>> Cryptography mailing list
>>> Cryptography at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>> cryptography
>>
>
>
More information about the Cryptography
mailing list