first cut at CertificateExtensions and ASN1 issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

first cut at CertificateExtensions and ASN1 issues

Rob Withers
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
Reply | Threaded
Open this post in threaded view
|

Re: first cut at CertificateExtensions and ASN1 issues

Rob Withers
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
Reply | Threaded
Open this post in threaded view
|

RE: first cut at CertificateExtensions and ASN1issues

Ron Teitelbaum
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
Reply | Threaded
Open this post in threaded view
|

Re: first cut at CertificateExtensions and ASN1issues

Rob Withers
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

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Reply | Threaded
Open this post in threaded view
|

RE: first cut at CertificateExtensions and ASN1issues

Ron Teitelbaum
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
>


_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Reply | Threaded
Open this post in threaded view
|

Re: first cut at CertificateExtensions and ASN1issues

Rob Withers
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
>>
>
>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Reply | Threaded
Open this post in threaded view
|

RE: first cut at CertificateExtensions and ASN1issues

Ron Teitelbaum
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
> >>
> >
> >
>


_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Reply | Threaded
Open this post in threaded view
|

Re: first cut at CertificateExtensions and ASN1issues

Rob Withers
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
>>>>
>>>
>>>
>>
>
>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Reply | Threaded
Open this post in threaded view
|

RE: first cut at CertificateExtensions and ASN1issues

Ron Teitelbaum
Nice job, Rob!!  Thanks for your work on this!

Ron

> -----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
> >>>>
> >>>
> >>>
> >>
> >
> >


_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography