[Mono-dev] Mono.Security: Error when loading a CRL in ASN1

[Jonathon Rossi]

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.

ASN1VE (http://www.obj-sys.com/products_asn1ve.php) threw up an error trying
to open it.

On Fri, Oct 16, 2009 at 10:09 PM, Sebastien Pouliot <
sebastien.pouliot at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20091018/17d20d3d/attachment.html