On 1/10/03 12:47 pm, Graham Barr <[EMAIL PROTECTED]> wrote:
> On 1 Oct 2003, at 9:05, Chris Ridd wrote:
>> my $exts = $asn->find("Extensions");
>> my $san = $asn->find("SubjectAltName");
>>
>> my $e = $exts->decode($binSan);
>> # So we look at the first extension, and decode that as a
>> SubjectAltName.
>> # Ideally we'd check $e->[0]->{extnID} against '2.5.29.17' first..
>> my $s = $san->decode($e->[0]->{extnValue});
>
> Ug, I hate that you have todo that. I was hoping we could do
It is an irritating part of ASN.1 (or way to abuse ASN.1!) IMO, and having a
nice way to deal with it would be cool.
> extnValue [UNIVERSAL 4] EXPLICIT ANY DEFINED BY extnID
>
> But that causes a parse error as it is expecting the tag to have the
> constructor bit set :(
>
> Maybe I could add an extension so we can write
>
> extnValue [UNIVERSAL 4] CONTAINING ANY DEFINED BY extnID
>
> Which is identical to explicit, but does not set the constructor bit
'ANY DEFINED BY' just encodes the actual value in place of the 'ANY', as far
as I know. This X.509 stuff is different - it encodes the value and then
encodes a real OCTET STRING containing the encoded value.
Either way, you'd need some sort of way to map from the OID to the syntax
definition of the ANY, or in this case of the thing embedded inside the
OCTET STRING. Apparently ASN.1 EXTERNAL lets you embed things inside BIT
STRINGs too, just to be flexible.
So you need to hold a mapping table for the OIDs <-> Type, and a way to
define how the inner thing is embedded.
Cheers,
Chris
