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
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@lists.squeakfoundation.org 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: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
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@lists.squeakfoundation.org [mailto:cryptography-bounces@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org 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:reefedjib@yahoo.com] Sent: Sunday, January 28, 2007 4:41 PM To: Ron@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@lists.squeakfoundation.org [mailto:cryptography-bounces@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
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@yahoo.com] Sent: Sunday, January 28, 2007 4:41 PM To: Ron@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@lists.squeakfoundation.org [mailto:cryptography-bounces@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org 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:reefedjib@yahoo.com] Sent: Sunday, January 28, 2007 11:05 PM To: Ron@USMedRec.com 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:reefedjib@yahoo.com] Sent: Sunday, January 28, 2007 4:41 PM To: Ron@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@lists.squeakfoundation.org [mailto:cryptography-bounces@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
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:reefedjib@yahoo.com] Sent: Sunday, January 28, 2007 11:05 PM To: Ron@USMedRec.com 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:reefedjib@yahoo.com] Sent: Sunday, January 28, 2007 4:41 PM To: Ron@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@lists.squeakfoundation.org [mailto:cryptography-bounces@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@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ > cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Nice job, Rob!! Thanks for your work on this!
Ron
-----Original Message----- From: Robert Withers [mailto:reefedjib@yahoo.com] Sent: Sunday, January 28, 2007 11:34 PM To: Ron@USMedRec.com 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:reefedjib@yahoo.com] Sent: Sunday, January 28, 2007 11:05 PM To: Ron@USMedRec.com 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:reefedjib@yahoo.com] Sent: Sunday, January 28, 2007 4:41 PM To: Ron@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@lists.squeakfoundation.org > [mailto:cryptography-bounces@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@lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ >> cryptography > > _______________________________________________ > Cryptography mailing list > Cryptography@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ > cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
cryptography@lists.squeakfoundation.org
-
Robert Withers -
Ron Teitelbaum