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