« Return to Thread: first cut at CertificateExtensions and ASN1 issues
RE: first cut at CertificateExtensions and ASN1issues
by Ron Teitelbaum
::
Rate this Message:
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@...]
> Sent: Sunday, January 28, 2007 4:41 PM
> To: Ron@...; 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@...
> >> [mailto:cryptography-bounces@...] 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@...
> >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>> cryptography
> >>
> >> _______________________________________________
> >> Cryptography mailing list
> >> Cryptography@...
> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >> cryptography
> >
> >
> > _______________________________________________
> > Cryptography mailing list
> > Cryptography@...
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> > cryptography
>
_______________________________________________
Cryptography mailing list
Cryptography@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
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@...]
> Sent: Sunday, January 28, 2007 4:41 PM
> To: Ron@...; 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@...
> >> [mailto:cryptography-bounces@...] 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@...
> >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>> cryptography
> >>
> >> _______________________________________________
> >> Cryptography mailing list
> >> Cryptography@...
> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >> cryptography
> >
> >
> > _______________________________________________
> > Cryptography mailing list
> > Cryptography@...
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> > cryptography
>
_______________________________________________
Cryptography mailing list
Cryptography@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
« Return to Thread: first cut at CertificateExtensions and ASN1 issues
| Free Forum Powered by Nabble | Forum Help |