first cut at CertificateExtensions and ASN1 issues

> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ 
> cryptography

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] 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
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> > cryptography
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

> 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: [hidden email]
>> [mailto:[hidden email]] 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
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>> cryptography
>>
>> _______________________________________________
>> Cryptography mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ 
>> cryptography
>
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ 
> cryptography

> -----Original Message-----
> From: Robert Withers [mailto:[hidden email]]
> Sent: Sunday, January 28, 2007 4:41 PM
> To: [hidden email]; 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: [hidden email]
> >> [mailto:[hidden email]] 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
> >>> [hidden email]
> >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>> cryptography
> >>
> >> _______________________________________________
> >> Cryptography mailing list
> >> [hidden email]
> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >> cryptography
> >
> >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> > cryptography
>

> 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:[hidden email]]
>> Sent: Sunday, January 28, 2007 4:41 PM
>> To: [hidden email]; 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: [hidden email]
>>>> [mailto:[hidden email]] 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
>>>>> [hidden email]
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>>>> cryptography
>>>>
>>>> _______________________________________________
>>>> Cryptography mailing list
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>>> cryptography
>>>
>>>
>>> _______________________________________________
>>> Cryptography mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>> cryptography
>>
>
>

> -----Original Message-----
> From: Robert Withers [mailto:[hidden email]]
> Sent: Sunday, January 28, 2007 11:05 PM
> To: [hidden email]
> Cc: 'Cryptography Team Development List'
> Subject: Re: [Cryptography Team] first cut at CertificateExtensions and
> ASN1issues
>
> 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:[hidden email]]
> >> Sent: Sunday, January 28, 2007 4:41 PM
> >> To: [hidden email]; 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: [hidden email]
> >>>> [mailto:[hidden email]] 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
> >>>>> [hidden email]
> >>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>>>> cryptography
> >>>>
> >>>> _______________________________________________
> >>>> Cryptography mailing list
> >>>> [hidden email]
> >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>>> cryptography
> >>>
> >>>
> >>> _______________________________________________
> >>> Cryptography mailing list
> >>> [hidden email]
> >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>> cryptography
> >>
> >
> >
>

> Rob,
>
> That's great.  I'm glad you made it work.  I agree nil is nice.
>
> I like the idea of using the class for both since it really is just a
> wrapper anyway.  Maybe a name change to remove Constructed, but we  
> could
> just leave it.
>
> What do you think?
>
> Ron
>
>> -----Original Message-----
>> From: Robert Withers [mailto:[hidden email]]
>> Sent: Sunday, January 28, 2007 11:05 PM
>> To: [hidden email]
>> Cc: 'Cryptography Team Development List'
>> Subject: Re: [Cryptography Team] first cut at  
>> CertificateExtensions and
>> ASN1issues
>>
>> 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:[hidden email]]
>>>> Sent: Sunday, January 28, 2007 4:41 PM
>>>> To: [hidden email]; 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: [hidden email]
>>>>>> [mailto:[hidden email]] 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
>>>>>>> [hidden email]
>>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>>>>>> cryptography
>>>>>>
>>>>>> _______________________________________________
>>>>>> Cryptography mailing list
>>>>>> [hidden email]
>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>>>>> cryptography
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Cryptography mailing list
>>>>> [hidden email]
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
>>>>> cryptography
>>>>
>>>
>>>
>>
>
>

> -----Original Message-----
> From: Robert Withers [mailto:[hidden email]]
> Sent: Sunday, January 28, 2007 11:34 PM
> To: [hidden email]
> Cc: 'Cryptography Team Development List'
> Subject: Re: [Cryptography Team] first cut at CertificateExtensions and
> ASN1issues
>
> hey Ron,
>
> I renamed the class as you suggested and consolidated all the asn1
> methods to the ASN1 package.   It's all published now.
>
> I don't know if I mentioned it but this gets CertificateExtensions
> working and encoding correctly for signatures.
>
> Rob
>
> On Jan 28, 2007, at 8:11 PM, Ron Teitelbaum wrote:
>
> > Rob,
> >
> > That's great.  I'm glad you made it work.  I agree nil is nice.
> >
> > I like the idea of using the class for both since it really is just a
> > wrapper anyway.  Maybe a name change to remove Constructed, but we
> > could
> > just leave it.
> >
> > What do you think?
> >
> > Ron
> >
> >> -----Original Message-----
> >> From: Robert Withers [mailto:[hidden email]]
> >> Sent: Sunday, January 28, 2007 11:05 PM
> >> To: [hidden email]
> >> Cc: 'Cryptography Team Development List'
> >> Subject: Re: [Cryptography Team] first cut at
> >> CertificateExtensions and
> >> ASN1issues
> >>
> >> 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:[hidden email]]
> >>>> Sent: Sunday, January 28, 2007 4:41 PM
> >>>> To: [hidden email]; 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: [hidden email]
> >>>>>> [mailto:[hidden email]] 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
> >>>>>>> [hidden email]
> >>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>>>>>> cryptography
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Cryptography mailing list
> >>>>>> [hidden email]
> >>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>>>>> cryptography
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Cryptography mailing list
> >>>>> [hidden email]
> >>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>>>> cryptography
> >>>>
> >>>
> >>>
> >>
> >
> >