[Cryptography Team] first cut at CertificateExtensions and ASN1issues

Mon Jan 29 04:11:05 UTC 2007

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