[classlib][ASN1]

[Tobias Braun <to...@gmx.de>]

Hello,

I have found a limitation or bug to the X.680 specification.

I get an "org.apache.harmony.security.asn1.ASN1Exception: ASN.1 UTCTime: 
wrong  format for DER, identifier at [182]"-Exception because the UTCTime 
isn't 13 characters.

        if (length != ASN1UTCTime.UTC_HMS) {
           throw new ASN1Exception(
                  "ASN.1 UTCTime: wrong format for DER, identifier at ["
                           + tagOffset + ']');
         }

The format is YYMMDDhhmm(ss)z. In accordance with X.680 specifications 
(http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf), 
there are also other formats allowed.
For example there is no need to transceive the seconds if they are 00. But 
then, the
UTCTime is only 11 characters long and a new ASN1Exception will be thrown 
and no
connection can be established.
So is there a planned enhancement on this validation check?

best regards
Tobias Braun    
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: [classlib][ASN1]

[Mark Hindess <ma...@googlemail.com>]

In message <20...@gmx.net>, "Tobias Braun" writes:
>
> Hello,
> 
> I have found a limitation or bug to the X.680 specification.
> 
> I get an "org.apache.harmony.security.asn1.ASN1Exception: ASN.1 UTCTime: 
> wrong  format for DER, identifier at [182]"-Exception because the UTCTime 
> isn't 13 characters.
> 
>         if (length != ASN1UTCTime.UTC_HMS) {
>            throw new ASN1Exception(
>                   "ASN.1 UTCTime: wrong format for DER, identifier at ["
>                            + tagOffset + ']');
>          }
> 
> The format is YYMMDDhhmm(ss)z. In accordance with X.680 specifications 
> (http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf), 
> there are also other formats allowed.
> For example there is no need to transceive the seconds if they are
> 00. But then, the UTCTime is only 11 characters long and a new
> ASN1Exception will be thrown and no connection can be established.
> So is there a planned enhancement on this validation check?

I'm not sure it would be valid.  For example, according to:

  http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

section 11.8.2:

  The seconds element shall always be present.

Do you think that this doesn't apply in this context?  If so, why?

Regards,
 Mark.