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

[Sebastien Pouliot]

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