[Cryptography Team] first cut at CertificateExtensions and ASN1issues

Ron Teitelbaum Ron at USMedRec.com
Mon Jan 29 13:53:48 UTC 2007 

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

Ron

> -----Original Message-----
> From: Robert Withers [mailto:reefedjib at yahoo.com]
> Sent: Sunday, January 28, 2007 11:34 PM
> To: Ron at 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 at yahoo.com]
> >> Sent: Sunday, January 28, 2007 11:05 PM
> >> To: Ron at 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 at yahoo.com]
> >>>> Sent: Sunday, January 28, 2007 4:41 PM
> >>>> To: Ron at 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 at lists.squeakfoundation.org
> >>>>>> [mailto:cryptography-bounces at 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 at lists.squeakfoundation.org
> >>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>>>>>> cryptography
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Cryptography mailing list
> >>>>>> Cryptography at lists.squeakfoundation.org
> >>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>>>>> cryptography
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Cryptography mailing list
> >>>>> Cryptography at lists.squeakfoundation.org
> >>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/
> >>>>> cryptography
> >>>>
> >>>
> >>>
> >>
> >
> >

More information about the Cryptography mailing list