On Sun, Oct 18, 2009 at 12:30 AM, Sebastien Pouliot < sebastien.poul...@gmail.com> wrote:
> On Sun, 2009-10-18 at 00:06 +1000, Jonathon Rossi wrote: > > Thanks for your prompt response Sebastien. > > > > I tried option B first, and things seemed to turn out worse than > > before. You can see from the stack trace below that the length is now > > 121, rather than 104; and it is deeper in the recursion. > > > > Mono.Security.dll!Mono.Security.ASN1.DecodeTLV(byte[] asn1 = > > {byte[69238]}, ref int pos = 69138, out byte tag = 43, out int length > > = 121, out byte[] content = {byte[121]}) Line 279 + 0x33 bytes > > Mono.Security.dll!Mono.Security.ASN1.Decode(byte[] asn1 = > > {byte[69238]}, ref int anPos = 69138, int anLength = 69201) Line 249 + > > 0x36 bytes > > Mono.Security.dll!Mono.Security.ASN1.Decode(byte[] asn1 = > > {byte[69238]}, ref int anPos = 69136, int anLength = 69238) Line 258 + > > 0x2b bytes > > Mono.Security.dll!Mono.Security.ASN1.Decode(byte[] asn1 = > > {byte[69238]}, ref int anPos = 69134, int anLength = 69238) Line 258 + > > 0x2b bytes > > Mono.Security.dll!Mono.Security.ASN1.ASN1(byte[] data = {byte[69238]}) > > Line 90 + 0x26 bytes > > Mono.Security.dll!Mono.Security.X509.X509Crl.Parse(byte[] crl = > > {byte[69238]}) Line 139 + 0x33 bytes > > Mono.Security.dll!Mono.Security.X509.X509Crl.X509Crl(byte[] crl = > > {byte[69238]}) Line 131 + 0x13 bytes > > > > I couldn't find the freeware asn1view tool you mention, but I tried > > some other ones I found in a google search. I can't build gasn1view on > > this machine so I couldn't try that one. > > > > ASN.1 Editor (http://lipingshare.com/Asn1Editor/) took 5mins to open > > the CRL and from what it shows the data ends at position 51088, which > > means there would be 18149 bytes of junk at the end? I cannot confirm > > whether it shows all revoked certificates in the sequence. > > Without confirmation about the entries or the CRL itself then no one can > say what are the last 18149 bytes. It could be extra junk or there could > be something corrupted. > I can send you a personal email with the CRL. Do you have time to look at this for me to determine if this is a mono bug or a corrupted crl? > > ASN1VE (http://www.obj-sys.com/products_asn1ve.php) threw up an error > > trying to open it. > > I can't be sure but I'll bet on a bad/damaged file. Did you said it was > working* somewhere ? (windows?) It could still be (somewhat) valid, e.g. > the important data is signed against tempering, but it's unlikely it > will work across systems. > I assume the CRL is working correctly on our Windows systems, it is at least not rejected by Windows. I'll have to test that. I just ran openssl asn1parse and it returned the same type of output that ASN1 Editor returned where there is empty data at the end. However, I just checked the version of openssl we have in our ca directory, and it is 0.9.6g (09/08/2002) so I think we should be upgrading. Thanks > > On Fri, Oct 16, 2009 at 10:09 PM, Sebastien Pouliot > > <sebastien.poul...@gmail.com> wrote: > > On Fri, 2009-10-16 at 11:40 +1000, Jonathon Rossi wrote: > > > Hi, > > > > > > I am trying to load a CRL with the Mono.Security library > > (tried with > > > the 2.4.2.3 Windows binaries, and with the trunk) like this: > > > X509Crl crl = X509Crl.CreateFromFile(@"C:\ca.crl"); > > > > > > And I get a CryptographicException: Input data cannot be > > coded as a > > > valid CRL. > > > > > > I have looking into the source code and this is occurring > > inside > > > ASN1.DecodeTLV. At this point the code is trying to do a > > block copy of > > > 104 bytes, where the asn1 array only has 103 left (pos > > +length), and it > > > throws an ArgumentException: "Offset and length were out of > > bounds for > > > the array or count is greater than the number of elements > > from index > > > to the end of the source collection." > > > > > > Mono.Security.dll!Mono.Security.ASN1.DecodeTLV(byte[] asn1 = > > > {byte[69237]}, ref int pos = 69134, out byte tag = 104, out > > int length > > > = 104, out byte[] content = {byte[104]}) Line 279 + 0x33 > > bytes > > > > > > It looks weird (but not impossible) that both the tag and > > length are > > 104. However the problem is that that's only 103 byte left in > > the buffer > > - which (if the length is valid) is not legal ASN.1 (but not > > unheard of > > either, e.g. extra bytes are common and accepted by most > > parsers) > > > > > Mono.Security.dll!Mono.Security.ASN1.Decode(byte[] asn1 = > > > {byte[69237]}, ref int anPos = 69134, int anLength = 69237) > > Line 249 + > > > 0x36 bytes > > > Mono.Security.dll!Mono.Security.ASN1.ASN1(byte[] data = > > {byte[69237]}) > > > Line 90 + 0x26 bytes > > > Mono.Security.dll!Mono.Security.X509.X509Crl.Parse(byte[] > > crl = > > > {byte[69237]}) Line 139 + 0x33 bytes > > > Mono.Security.dll!Mono.Security.X509.X509Crl.X509Crl(byte[] > > crl = > > > {byte[69237]}) Line 131 + 0x13 bytes > > > Mono.Security.dll! > > Mono.Security.X509.X509Crl.CreateFromFile(string > > > filename = "C:\\ca.crl") Line 421 + 0x20 bytes > > > ConsoleApplication2.exe! > > ConsoleApplication2.Program.Main(string[] args > > > = {string[0]}) Line 14 + 0x12 bytes > > > > > > The CRL is 68KB, and verifies using certutil. > > > > > > If the parser allows the truncation then the CRL can still > > verify if the > > missing part (the last byte in this case) is not part of the > > signed data > > of the CRL (e.g. its common to have unauthenticated attributes > > in ASN.1 > > structures). This *could* be the case here (can't be sure > > without the > > actual data). > > > > > I cannot provide the CRL, however any pointers on what could > > be > > > causing this would be really helpful. > > > > > > You can: > > > > (a) try loading the CRL into asn1view (windows freeware) or > > gasnview > > (.net application in mono-tools, which requires gtk#) and look > > at what > > data exists at position 69134 > > > > (b) load the CRL manually and copy it into a byte[] array that > > is one > > byte larger than the original one - that will validate the > > above theory. > > That's a lame workaround since it's specific to the current > > CRL you > > have. > > > > (c) open a bug report at bugzilla.novell.com and attach the > > CRL as a > > private attachment (only Novell employees will see it) > > > > (d) open a bug report at bugzilla.novell.com and attach the > > CRL and > > email me the CRL separately (only I will see it) > > > > Sebastien > > > > > > > > > > -- > > Jono > > -- Jono
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list