From owner-imc-snacc Mon Apr 17 06:37:14 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA02013 for imc-snacc-bks; Mon, 17 Apr 2000 06:37:14 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02009 for ; Mon, 17 Apr 2000 06:37:12 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Apr 2000 09:40:48 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31965D93@wfhqex01.wangfed.com> From: "Pawling, John" To: "'imc-snacc@imc.org'" Subject: SNACC ASN.1 Freeware Release & Mail List Date: Mon, 17 Apr 2000 09:40:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, J. G. Van Dyke and Associates (VDA), a Wang Government Services Company, has delivered an enhanced version of the freeware SNACC v1.3 rev 0.07 Abstract Syntax Notation.1 (ASN.1) Compiler and Library. In past releases, VDA enhanced the C++ version of the SNACC library to implement the Distinguished Encoding Rules (DER). In the new release, VDA enhanced the C and C++ versions of the SNACC library to support PrintableString, TeletexString, NumericString, IA5String, VisibileString, BMPString, UniversalString and UTF8String character string types. We added an optional function to SNACC that can be used to convert ASN.1 OCTET STRINGs to single- or multi-byte character strings (as appropriate). This is needed to support the RFC 2459 PKIX requirements. The SNACC enhancement is completely optional and does not impact existing code that uses SNACC. The SNACC library decodes an object as it always has. If the application/library needs the ASN.1 OCTET STRINGs converted to character strings, then it calls the new SNACC function/class to perform the conversion. If an application/library does not need the ASN.1 OCTET STRINGs converted, then it does not need to call the conversion function/classes and can use the SNACC-generated structures/classes as always. The VDA-enhanced SNACC compiler and C++ library is available along with the S/MIME Freeware Library (SFL) that uses SNACC to implement the S/MIME v3 set of specifications. The snacc1_6VDA.zip file contains the SNACC v1.3 rev 0.07 ASN.1 Compiler and C++ Library source code compilable for Unix and MS Windows NT/95/98/2000. The VDA-enhanced SNACC C library is available along with the freeware Certificate Management Library (CML) that uses SNACC to implement the 1997 X.509 Recommendation and RFC 2459. The CML17sr.tar.Z file includes the source code for the CML and VDA-enhanced SNACC C library compilable for Unix and MS Windows NT/95/98/2000. We plan to consolidate the enhancements made by VDA to the C and C++ versions of the SNACC source code into a single baseline that can be delivered in a single tar/zip file. In the new release, we also corrected a bug in the DEC_LOAD_ANYBUF macro. We changed "bytesDecoded" to "bytesDecodedXX" to avoid conflict other SNACC uses of the "bytesDecoded" variable. We also enhanced the AsnOid method so that it accepts a dynamic number of components within an object identifier. SNACC implements the majority of ASN.1 encoding/decoding rules. SNACC does not support all of the latest ASN.1 features, but there are work-arounds that allow SNACC to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1 syntax modules which can be directly compiled using SNACC. The SNACC ASN.1 library is totally unencumbered as stated in the SFL Public License. All source code for the VDA-enhanced SNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the VDA-enhanced SNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established a SNACC web page . The IMC has also established a SNACC mail list which is used to: distribute information regarding SNACC releases; discuss SNACC-related issues; and provide a means for SNACC users to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. VDA welcomes all feedback regarding the VDA-enhanced SNACC software. If bugs are reported, then VDA will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. We recommend that comments should be sent to the imc-snacc mail list. We will respond to all messages on that list. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ From owner-imc-snacc Tue Apr 18 10:02:51 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06449 for imc-snacc-bks; Tue, 18 Apr 2000 10:02:51 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06445 for ; Tue, 18 Apr 2000 10:02:50 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Apr 2000 13:06:32 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31965DBA@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.6 SFL/SNACC Patch Files Date: Tue, 18 Apr 2000 13:06:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, A bug has been reported in the v1.6 S/MIME Freeware Library (SFL) and accompanying SNACC C++ library. We strongly recommend that the patch files (described below) should be immediately incorporated into your local version of the SFL and SNACC C++ software. Much thanks to Dan Teodosescu, Foliage Software Systems, for reporting this bug. We encourage all feedback related to the SFL and SNACC software. We made the changes in the SFL and SNACC C++ baseline software as described below and successfully tested the corrected software. The corrected SFL and SNACC C++ source code files are stored on the Fortezza Developer's S/MIME Page under "sflpatch 4/18/00". We do not plan to deliver a new release of the SFL and SNACC C++ software solely to fix this bug. This bug does not impact the Certificate Management Library. We added the following text to the SFL Problem Report File available in the "sflpatch 4/18/00" zip file: SFL PROBLEM REPORT FILE 17 April 2000 This file documents errors in the v1.6 S/MIME Freeware Library (SFL) that have not yet been included in a new release of the SFL. ====================================================================== Problem Report #1 File(s) Affected: sm_buffer.h, sm_vdasnacc.cpp, sm_buffer.cpp, vdatest.cpp Date Reported: 12 April 2000 Problem Description: When the v1.6 SFL is used to create a signedData object larger than 16K bytes, then temporary files containing the signedData object are not removed from the root directory of the working drive. Platform(s) affected: All Resolution: SNACC was leaving temporary files in the root directory when any object larger than 16K was ASN.1 encoded. The sm_buffer.h, sm_vdasnacc.cpp, sm_buffer.cpp, vdatest.cpp patch files fix the problem. These files belong in the SNACC release c++-lib inc and src directories. The file "sm_buffer.h" MUST also be copied to the sfl directory "./include/snacc/c++" to be effective. There will be a few SFL baseline build errors due to the CSM_Buffer update; on each error add "(size_t)" override on the CSM_Buffer constructor parameter (there are only 8 or so errors). Baseline Source Code Fixed and Tested: 17 April 2000 For more information, contact: ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc; a Wang Government Services Company john.pawling@wang.com ============================================ From owner-imc-snacc Fri Jul 14 14:06:37 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA15012 for imc-snacc-bks; Fri, 14 Jul 2000 14:06:37 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15008 for ; Fri, 14 Jul 2000 14:06:36 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <3GNFB4P4>; Fri, 14 Jul 2000 17:07:41 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0016D013F@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.3 Enhanced SNACC ASN.1 Freeware Release Date: Fri, 14 Jul 2000 17:07:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Wang Government Services, Inc. (WGSI), A Getronics Company, has delivered the v1.3 Enhanced SNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Sun Solaris 2.7 and Microsoft Windows NT/95/98/2000. The source code and the Enhanced SNACC Software Public License are freely available to everyone from: . In past releases, WGSI enhanced the C++ version of the SNACC library to implement the Distinguished Encoding Rules (DER). In the v1.3 SNACC release, WGSI included the following enhancements in SNACC: 1) Completed merging SNACC C and C++ enhancements made by U.S. Government and WGSI into a single source code baseline that we have delivered in a single tar file. 2) Added DER source code developed by Australian OSCAR project to SNACC C library. 3) Reconstructed and tested SNACC baseline so that all changes are documented using SourceSafe configuration management tool. 4) Resolved inconsistencies in how string types were implemented (imported versus internal) in C and C++ SNACC libraries. Changed SNACC C++ library to use same internal representation used by SNACC C library. 5) Tested C and C++ SNACC libraries on MS Windows and Solaris 2.7. 6) Tested v1.3 SNACC compiler and C++ library with the v1.7 S/MIME Freeware Library (SFL) that uses SNACC to implement the IETF S/MIME v3 set of specifications. 7) Tested v1.3 SNACC compiler, C and C++ libraries with the freeware v1.71 Certificate Management Library (CML) that uses SNACC to implement the 1997 X.509 Recommendation and RFC 2459. 8) Tested v1.3 SNACC compiler and C++ library with the freeware v1.3 Access Control Library (ACL) that uses SNACC to provide automated access control. SNACC implements the majority of ASN.1 encoding/decoding rules. SNACC does not support all of the latest ASN.1 features, but there are work-arounds that allow SNACC to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1 syntax modules which can be directly compiled using SNACC. The SNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the Enhanced SNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the Enhanced SNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established a SNACC web page . The IMC has also established a SNACC mail list which is used to: distribute information regarding SNACC releases; discuss SNACC-related issues; and provide a means for SNACC users to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. WGSI welcomes all feedback regarding the Enhanced SNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This SNACC release announcement was sent to several mail lists, but please send all messages regarding the Enhanced SNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the Enhanced SNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ From owner-imc-snacc Thu Sep 14 09:31:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA25387 for imc-snacc-bks; Thu, 14 Sep 2000 09:31:19 -0700 (PDT) Received: from exch-bhs-2.redstone.army.mil (exch-bhs-2.redstone.army.mil [136.205.13.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25383 for ; Thu, 14 Sep 2000 09:31:16 -0700 (PDT) Received: by exch-bhs-2.redstone.army.mil with Internet Mail Service (5.5.2448.0) id ; Thu, 14 Sep 2000 11:35:00 -0500 Message-ID: <1345B59AC3C5D211975E00A0C99DAC7A01B67559@exch-msg-6> From: "Nord, John D Contractor/NCCIM" To: "'imc-snacc'" Subject: little endian bug? Date: Thu, 14 Sep 2000 11:34:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I wasn't sure which list to send this to. I was thinking about sending it to all three (SNACC, SFL, and CML), but that would probably make a lot of people get three copies of it. The problem occurs in the SNACC library, but involves the SFL and CML as well. Description of bug: I'm using the DOD PKCS#12 file from the "email" link on web page http://www.disa.mil/infosec/pki-int.html. I'm using the SFL to create P7M files, and the CML to store certificates on a Windows platform. I noticed that the certificate from the P12 file (CN=Nimeh.Jamil.Joseph...) was getting added to the CML database twice. Everything about the two certificates in the CML database looked identical. However, a close inspection reveals that the certificates differ in one byte. The first byte of the certificate signature, which should be a leading '0', is correctly '0' in one certificate, but is '1' in the other certificate. The invalid certificate came from one of the P7M files created by the SFL. When the P7M file is created, the certificate is incorrectly encoded with a leading '1' instead of a leading '0' in front of the certificate signature. When my application opens the P7M, the signer's certificate (the invalid one in the P7M) is added to the CML database, so that both the valid and invalid certificates are now present. The call stack at the point at which the signature is encoded is: AsnBits::BEncContent(AsnBuf & {...}) Certificate::BEncContent(AsnBuf & {...}) CertificateChoices::BEncContent(AsnBuf & {...}) CertificateSet::BEncContent(AsnBuf & {...}) SignedData::BEncContent(AsnBuf & {...}) SignedData::BEnc(AsnBuf & {...}) SignedData::BEncPdu(AsnBuf & {...}, unsigned int &) CSM_DataToSign::Sign(CSMIME *, CSM_MsgCertCrls *, CSM_Buffer * &) CSM_MsgToSign::UpdateSignedDataSIs(CSMIME *) CSM_MsgToSign::Sign(CSMIME *) At the beginning of the function "AsnBits::BEncContent", the 'bitLen' member is 1024, the length of the signature. At line 274 (in snacc13rn\c++-lib\src\asn-bits.cpp) of this function, there is a sequence of statements intended to remove leading '0' bits from the bit sequence. However, the code begins looking at the LEAST significant byte of the signature instead of the most significant byte. To illustrate this, the bottom of the certificate cut from an ASN.1 view looks like: 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 [id_Sha1WithRSAEncryption] 05 00 03 81 81 00 a6 3e f9 9e d0 b3 52 de 61 8f fe ec 6c 95 43 ed c6 74 1a fa e2 81 43 d4 b7 30 62 e6 0e 52 cb 64 bc bf 31 45 a9 69 28 3e 73 b5 35 c6 f3 6c fc 5a 69 ef 19 c7 47 e0 d1 51 3c bc 0d de fb b5 4f 6a 09 c0 4a 8e 4a 54 11 ce fc 3a 0f 7b 26 2b 68 48 b5 4e 8b 27 7e fb aa ee 36 7a 8a 2a 5b b3 0d 9c f7 a6 d6 2c d4 e0 04 17 99 10 64 1f 2b a4 00 b1 4b 47 a6 fc a1 69 e6 2f 12 78 51 92 e6 2b 09 9e It can be seen from looking at the certificate that the most significant byte of the signature is 'A6', and the least significant is '9E'. When "AsnBits::BEncContent" calls "AsnBits::GetBit", it calls it with an argument of '1023'. "AsnBits::GetBit" assumes that the bit buffer is in a big endian order, and examines the byte '9E' to determine if the first bit is zero. Since the first bit of '9E' just happens to be zero, the signature bit sequence length is decremented to be 1023. This causes the "AsnBits::BEncContent" function to determine that there is one unused bit in the bit string, which in turn causes the signature being incorrectly encoded with a leading '1'. Either the buffer that is passed into "AsnBits::BEncContent" needs to be byte reversed, or the function "AsnBits::GetBit" needs to have an ifdef in it for little endian platforms. Does this sound right? John Nord From owner-imc-snacc Tue Sep 19 07:22:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24346 for imc-snacc-bks; Tue, 19 Sep 2000 07:22:54 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24325; Tue, 19 Sep 2000 07:22:44 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Sep 2000 10:26:35 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B1455@wfhqex01.wangfed.com> From: "Pawling, John" To: imc-cml@imc.org, imc-snacc@imc.org Subject: FW: UTF-8 Date: Tue, 19 Sep 2000 10:25:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA24326 Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, The attached message documents a bug in the v1.3 R3 Enhanced SNACC C library. It does not impact the SNACC C++ library. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ -----Original Message----- From: Colestock, Robert Sent: Tuesday, September 19, 2000 10:21 AM To: 'eboudreault@motus.com' Cc: Pawling, John; McPherson, Clyde Subject: RE: UTF-8 Eric: I believe you are correct, the 11th position in the enum array sets the wrong tag. This has been fixed in the next SNACC baseline. For you, simply add "=12" to the UTF8 tag value and re-build the SNACC "C" library: UTF8STRING_TAG_CODE, CHANGE TO UTF8STRING_TAG_CODE=12, Bob Colestock VDA -----Original Message----- From: eboudreault@motus.com [mailto:eboudreault@motus.com] Sent: Monday, September 18, 2000 3:40 PM To: imc-cml@imc.org Subject: UTF-8 Hello !!! I think i've found a bug in the file "asn-tag.h". There is the line of that bug : ..... typedef enum { NO_TAG_CODE = 0, BOOLEAN_TAG_CODE = 1, INTEGER_TAG_CODE, BITSTRING_TAG_CODE, OCTETSTRING_TAG_CODE, NULLTYPE_TAG_CODE, OID_TAG_CODE, OD_TAG_CODE, EXTERNAL_TAG_CODE, REAL_TAG_CODE, ENUM_TAG_CODE, UTF8STRING_TAG_CODE, SEQ_TAG_CODE = 16, SET_TAG_CODE, NUMERICSTRING_TAG_CODE, PRINTABLESTRING_TAG_CODE, TELETEXSTRING_TAG_CODE, VIDEOTEXSTRING_TAG_CODE, IA5STRING_TAG_CODE, UTCTIME_TAG_CODE, GENERALIZEDTIME_TAG_CODE, GRAPHICSTRING_TAG_CODE, VISIBLESTRING_TAG_CODE, GENERALSTRING_TAG_CODE, UNIVERSALSTRING_TAG_CODE = 28, BMPSTRING_TAG_CODE = 30 } BER_UNIV_CODE; ..... The bug is that the UTF8STRING_TAG_CODE is supposed to be 12 (11 now) as mentionned in the specification (rfc2459) and in the file asn-usefulVDA.h. What do think about that ???? And what can i do to correct that bug (if bug exist) ???? Thanks !! **************************************************************************** ****************** Eric Boudreault ------------------------------------------------ Programmeur ------------------------------------------------ Motus Technologies 390, St-Vallier Est Bureau 100 Québec, Qc G1K 3P6 Tél.: 521-2100 ext.#242 Fax.: 521-2101 couriel: eboudreault@motus.com **************************************************************************** ****************** From owner-imc-snacc Tue Sep 19 08:17:50 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA27706 for imc-snacc-bks; Tue, 19 Sep 2000 08:17:50 -0700 (PDT) Received: from mail.motus.qc.ca (motus.qc.ca [207.236.155.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27677; Tue, 19 Sep 2000 08:17:46 -0700 (PDT) From: eboudreault@motus.com Subject: Re: FW: UTF-8 To: "Pawling, John" Cc: imc-cml@imc.org, imc-snacc@imc.org, owner-imc-cml@mail.imc.org X-Mailer: Lotus Notes France (Canada) 5.0 14 avril 1999 Message-ID: Date: Tue, 19 Sep 2000 11:20:31 -0400 X-MIMETrack: Serialize by Router on motus1/Motus Technologies Inc.(Release 5.0.3 |March 21, 2000) at 19/09/2000 11:21:04 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA27686 Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Why UTF-8 is not included in the file asn-tag.h ??? ----------------------------------------------------------- ...... typedef enum BER_UNIV_CODE { NO_TAG_CODE = 0, BOOLEAN_TAG_CODE = 1, INTEGER_TAG_CODE, BITSTRING_TAG_CODE, OCTETSTRING_TAG_CODE, NULLTYPE_TAG_CODE, OID_TAG_CODE, OD_TAG_CODE, EXTERNAL_TAG_CODE, REAL_TAG_CODE, ENUM_TAG_CODE, SEQ_TAG_CODE = 16, SET_TAG_CODE, NUMERICSTRING_TAG_CODE, PRINTABLESTRING_TAG_CODE, TELETEXSTRING_TAG_CODE, VIDEOTEXSTRING_TAG_CODE, IA5STRING_TAG_CODE, UTCTIME_TAG_CODE, GENERALIZEDTIME_TAG_CODE, GRAPHICSTRING_TAG_CODE, VISIBLESTRING_TAG_CODE, #ifndef VDADER_RULES GENERALSTRING_TAG_CODE #else GENERALSTRING_TAG_CODE, UNIVERSALSTRING_TAG_CODE = 28, BMPSTRING_TAG_CODE = 30 #endif } BER_UNIV_CODE; ........ ----------------------------------------------------------- Why this does not impact the SNACC C++ library ????? ********************************************************************************************** Eric Boudreault ------------------------------------------------ Programmeur ------------------------------------------------ Motus Technologies 390, St-Vallier Est Bureau 100 Québec, Qc G1K 3P6 Tél.: 521-2100 ext.#242 Fax.: 521-2101 couriel: eboudreault@motus.com ********************************************************************************************** "Pawling, John" cc: Sent by: Subject: FW: UTF-8 owner-imc-cml@ma il.imc.org 19/09/00 10:25 All, The attached message documents a bug in the v1.3 R3 Enhanced SNACC C library. It does not impact the SNACC C++ library. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ -----Original Message----- From: Colestock, Robert Sent: Tuesday, September 19, 2000 10:21 AM To: 'eboudreault@motus.com' Cc: Pawling, John; McPherson, Clyde Subject: RE: UTF-8 Eric: I believe you are correct, the 11th position in the enum array sets the wrong tag. This has been fixed in the next SNACC baseline. For you, simply add "=12" to the UTF8 tag value and re-build the SNACC "C" library: UTF8STRING_TAG_CODE, CHANGE TO UTF8STRING_TAG_CODE=12, Bob Colestock VDA -----Original Message----- From: eboudreault@motus.com [mailto:eboudreault@motus.com] Sent: Monday, September 18, 2000 3:40 PM To: imc-cml@imc.org Subject: UTF-8 Hello !!! I think i've found a bug in the file "asn-tag.h". There is the line of that bug : ..... typedef enum { NO_TAG_CODE = 0, BOOLEAN_TAG_CODE = 1, INTEGER_TAG_CODE, BITSTRING_TAG_CODE, OCTETSTRING_TAG_CODE, NULLTYPE_TAG_CODE, OID_TAG_CODE, OD_TAG_CODE, EXTERNAL_TAG_CODE, REAL_TAG_CODE, ENUM_TAG_CODE, UTF8STRING_TAG_CODE, SEQ_TAG_CODE = 16, SET_TAG_CODE, NUMERICSTRING_TAG_CODE, PRINTABLESTRING_TAG_CODE, TELETEXSTRING_TAG_CODE, VIDEOTEXSTRING_TAG_CODE, IA5STRING_TAG_CODE, UTCTIME_TAG_CODE, GENERALIZEDTIME_TAG_CODE, GRAPHICSTRING_TAG_CODE, VISIBLESTRING_TAG_CODE, GENERALSTRING_TAG_CODE, UNIVERSALSTRING_TAG_CODE = 28, BMPSTRING_TAG_CODE = 30 } BER_UNIV_CODE; ..... The bug is that the UTF8STRING_TAG_CODE is supposed to be 12 (11 now) as mentionned in the specification (rfc2459) and in the file asn-usefulVDA.h. What do think about that ???? And what can i do to correct that bug (if bug exist) ???? Thanks !! **************************************************************************** ****************** Eric Boudreault ------------------------------------------------ Programmeur ------------------------------------------------ Motus Technologies 390, St-Vallier Est Bureau 100 Québec, Qc G1K 3P6 Tél.: 521-2100 ext.#242 Fax.: 521-2101 couriel: eboudreault@motus.com **************************************************************************** ****************** From owner-imc-snacc Tue Sep 19 09:35:33 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA02699 for imc-snacc-bks; Tue, 19 Sep 2000 09:35:33 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02687; Tue, 19 Sep 2000 09:35:21 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Sep 2000 12:39:09 -0400 Message-ID: <57B5672B24E6D2118165006008A5925969E6FA@wfhqex06.wangfed.com> From: "Colestock, Robert" To: "'eboudreault@motus.com'" Cc: "'imc-cml@imc.org'" , "'imc-snacc@imc.org'" , "'owner-imc-cml@mail.imc.org'" Subject: RE: FW: UTF-8 Date: Tue, 19 Sep 2000 12:38:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA02688 Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric: The C++ DER rules were implemented separate from the "C" DER rules (added later from freeware sources). The SNACC compiler changes necessary to implement the rules had to be compromised to reflect the different approaches. The short answer is that this reference does not affect the C++ tag encode/decode operations (the C++ reference to the tag is in ./specs/asn-usefulVDA.asn1). Bob Colestock VDA -----Original Message----- From: eboudreault@motus.com [mailto:eboudreault@motus.com] Sent: Tuesday, September 19, 2000 11:21 AM To: Pawling, John Cc: imc-cml@imc.org; imc-snacc@imc.org; owner-imc-cml@mail.imc.org Subject: Re: FW: UTF-8 Why UTF-8 is not included in the file asn-tag.h ??? ----------------------------------------------------------- ...... typedef enum BER_UNIV_CODE { NO_TAG_CODE = 0, BOOLEAN_TAG_CODE = 1, INTEGER_TAG_CODE, BITSTRING_TAG_CODE, OCTETSTRING_TAG_CODE, NULLTYPE_TAG_CODE, OID_TAG_CODE, OD_TAG_CODE, EXTERNAL_TAG_CODE, REAL_TAG_CODE, ENUM_TAG_CODE, SEQ_TAG_CODE = 16, SET_TAG_CODE, NUMERICSTRING_TAG_CODE, PRINTABLESTRING_TAG_CODE, TELETEXSTRING_TAG_CODE, VIDEOTEXSTRING_TAG_CODE, IA5STRING_TAG_CODE, UTCTIME_TAG_CODE, GENERALIZEDTIME_TAG_CODE, GRAPHICSTRING_TAG_CODE, VISIBLESTRING_TAG_CODE, #ifndef VDADER_RULES GENERALSTRING_TAG_CODE #else GENERALSTRING_TAG_CODE, UNIVERSALSTRING_TAG_CODE = 28, BMPSTRING_TAG_CODE = 30 #endif } BER_UNIV_CODE; ........ ----------------------------------------------------------- Why this does not impact the SNACC C++ library ????? **************************************************************************** ****************** Eric Boudreault ------------------------------------------------ Programmeur ------------------------------------------------ Motus Technologies 390, St-Vallier Est Bureau 100 Québec, Qc G1K 3P6 Tél.: 521-2100 ext.#242 Fax.: 521-2101 couriel: eboudreault@motus.com **************************************************************************** ****************** "Pawling, John" cc: Sent by: Subject: FW: UTF-8 owner-imc-cml@ma il.imc.org 19/09/00 10:25 All, The attached message documents a bug in the v1.3 R3 Enhanced SNACC C library. It does not impact the SNACC C++ library. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ -----Original Message----- From: Colestock, Robert Sent: Tuesday, September 19, 2000 10:21 AM To: 'eboudreault@motus.com' Cc: Pawling, John; McPherson, Clyde Subject: RE: UTF-8 Eric: I believe you are correct, the 11th position in the enum array sets the wrong tag. This has been fixed in the next SNACC baseline. For you, simply add "=12" to the UTF8 tag value and re-build the SNACC "C" library: UTF8STRING_TAG_CODE, CHANGE TO UTF8STRING_TAG_CODE=12, Bob Colestock VDA -----Original Message----- From: eboudreault@motus.com [mailto:eboudreault@motus.com] Sent: Monday, September 18, 2000 3:40 PM To: imc-cml@imc.org Subject: UTF-8 Hello !!! I think i've found a bug in the file "asn-tag.h". There is the line of that bug : ..... typedef enum { NO_TAG_CODE = 0, BOOLEAN_TAG_CODE = 1, INTEGER_TAG_CODE, BITSTRING_TAG_CODE, OCTETSTRING_TAG_CODE, NULLTYPE_TAG_CODE, OID_TAG_CODE, OD_TAG_CODE, EXTERNAL_TAG_CODE, REAL_TAG_CODE, ENUM_TAG_CODE, UTF8STRING_TAG_CODE, SEQ_TAG_CODE = 16, SET_TAG_CODE, NUMERICSTRING_TAG_CODE, PRINTABLESTRING_TAG_CODE, TELETEXSTRING_TAG_CODE, VIDEOTEXSTRING_TAG_CODE, IA5STRING_TAG_CODE, UTCTIME_TAG_CODE, GENERALIZEDTIME_TAG_CODE, GRAPHICSTRING_TAG_CODE, VISIBLESTRING_TAG_CODE, GENERALSTRING_TAG_CODE, UNIVERSALSTRING_TAG_CODE = 28, BMPSTRING_TAG_CODE = 30 } BER_UNIV_CODE; ..... The bug is that the UTF8STRING_TAG_CODE is supposed to be 12 (11 now) as mentionned in the specification (rfc2459) and in the file asn-usefulVDA.h. What do think about that ???? And what can i do to correct that bug (if bug exist) ???? Thanks !! **************************************************************************** ****************** Eric Boudreault ------------------------------------------------ Programmeur ------------------------------------------------ Motus Technologies 390, St-Vallier Est Bureau 100 Québec, Qc G1K 3P6 Tél.: 521-2100 ext.#242 Fax.: 521-2101 couriel: eboudreault@motus.com **************************************************************************** ****************** From owner-imc-snacc Fri Sep 22 10:54:21 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA12611 for imc-snacc-bks; Fri, 22 Sep 2000 10:54:21 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12603 for ; Fri, 22 Sep 2000 10:54:19 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Sep 2000 13:58:04 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B14C1@wfhqex01.wangfed.com> From: "Pawling, John" To: imc-snacc@imc.org Cc: "Leonberger, Pierce" , "Colestock, Robert" Subject: RE: little endian bug? Date: Fri, 22 Sep 2000 13:58:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, We apologize for taking so long to respond to your message. We agree that you have identified a bug in the Enhanced SNACC library. We have fixed this bug in the baseline Enhanced SNACC source code. Since the release of the v1.3 R2 Enhanced SNACC source code, we have also fixed bugs that caused BIT STRINGs and default values to be improperly DER encoded. On 30 Sep 00, we plan to deliver the v1.3 R4 Enhanced SNACC ASN.1 Compiler and Library source code that fixes all of the bugs. We apologize for any inconvenience caused by these bugs. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ -----Original Message----- From: Nord, John D Contractor/NCCIM [mailto:john.nord@redstone.army.mil] Sent: Thursday, September 14, 2000 12:34 PM To: 'imc-snacc' Subject: little endian bug? I wasn't sure which list to send this to. I was thinking about sending it to all three (SNACC, SFL, and CML), but that would probably make a lot of people get three copies of it. The problem occurs in the SNACC library, but involves the SFL and CML as well. Description of bug: I'm using the DOD PKCS#12 file from the "email" link on web page http://www.disa.mil/infosec/pki-int.html. I'm using the SFL to create P7M files, and the CML to store certificates on a Windows platform. I noticed that the certificate from the P12 file (CN=Nimeh.Jamil.Joseph...) was getting added to the CML database twice. Everything about the two certificates in the CML database looked identical. However, a close inspection reveals that the certificates differ in one byte. The first byte of the certificate signature, which should be a leading '0', is correctly '0' in one certificate, but is '1' in the other certificate. The invalid certificate came from one of the P7M files created by the SFL. When the P7M file is created, the certificate is incorrectly encoded with a leading '1' instead of a leading '0' in front of the certificate signature. When my application opens the P7M, the signer's certificate (the invalid one in the P7M) is added to the CML database, so that both the valid and invalid certificates are now present. The call stack at the point at which the signature is encoded is: AsnBits::BEncContent(AsnBuf & {...}) Certificate::BEncContent(AsnBuf & {...}) CertificateChoices::BEncContent(AsnBuf & {...}) CertificateSet::BEncContent(AsnBuf & {...}) SignedData::BEncContent(AsnBuf & {...}) SignedData::BEnc(AsnBuf & {...}) SignedData::BEncPdu(AsnBuf & {...}, unsigned int &) CSM_DataToSign::Sign(CSMIME *, CSM_MsgCertCrls *, CSM_Buffer * &) CSM_MsgToSign::UpdateSignedDataSIs(CSMIME *) CSM_MsgToSign::Sign(CSMIME *) At the beginning of the function "AsnBits::BEncContent", the 'bitLen' member is 1024, the length of the signature. At line 274 (in snacc13rn\c++-lib\src\asn-bits.cpp) of this function, there is a sequence of statements intended to remove leading '0' bits from the bit sequence. However, the code begins looking at the LEAST significant byte of the signature instead of the most significant byte. To illustrate this, the bottom of the certificate cut from an ASN.1 view looks like: 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 [id_Sha1WithRSAEncryption] 05 00 03 81 81 00 a6 3e f9 9e d0 b3 52 de 61 8f fe ec 6c 95 43 ed c6 74 1a fa e2 81 43 d4 b7 30 62 e6 0e 52 cb 64 bc bf 31 45 a9 69 28 3e 73 b5 35 c6 f3 6c fc 5a 69 ef 19 c7 47 e0 d1 51 3c bc 0d de fb b5 4f 6a 09 c0 4a 8e 4a 54 11 ce fc 3a 0f 7b 26 2b 68 48 b5 4e 8b 27 7e fb aa ee 36 7a 8a 2a 5b b3 0d 9c f7 a6 d6 2c d4 e0 04 17 99 10 64 1f 2b a4 00 b1 4b 47 a6 fc a1 69 e6 2f 12 78 51 92 e6 2b 09 9e It can be seen from looking at the certificate that the most significant byte of the signature is 'A6', and the least significant is '9E'. When "AsnBits::BEncContent" calls "AsnBits::GetBit", it calls it with an argument of '1023'. "AsnBits::GetBit" assumes that the bit buffer is in a big endian order, and examines the byte '9E' to determine if the first bit is zero. Since the first bit of '9E' just happens to be zero, the signature bit sequence length is decremented to be 1023. This causes the "AsnBits::BEncContent" function to determine that there is one unused bit in the bit string, which in turn causes the signature being incorrectly encoded with a leading '1'. Either the buffer that is passed into "AsnBits::BEncContent" needs to be byte reversed, or the function "AsnBits::GetBit" needs to have an ifdef in it for little endian platforms. Does this sound right? John Nord From owner-imc-snacc Thu Oct 12 10:23:09 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA09923 for imc-snacc-bks; Thu, 12 Oct 2000 10:23:09 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09918 for ; Thu, 12 Oct 2000 10:23:08 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Oct 2000 13:30:23 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B1661@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.3 R4 Enhanced SNACC ASN.1 Freeware Now Available Date: Thu, 12 Oct 2000 13:27:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Getronics Government Solutions (GGS) (formerly Wang Government Services) has delivered the v1.3 R4 Enhanced SNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.7 and Microsoft Windows NT/95/98/2000. The source code and the Enhanced SNACC Software Public License are freely available to everyone from: . In past releases, GGS enhanced the SNACC library to implement the Distinguished Encoding Rules (DER). In the v1.3 R4 SNACC release, GGS included the following enhancements: 1) Corrected bug that caused BIT STRINGs to be improperly DER encoded. 2) Corrected bug that caused BOOLEAN DEFAULT, INTEGER DEFAULT, and BIT STRING DEFAULT values to be improperly DER encoded. 3) Tested with v1.8 S/MIME Freeware Library (SFL) that uses SNACC to implement the IETF S/MIME v3 set of specifications. 4) Tested with freeware v1.8 Certificate Management Library (CML) that uses SNACC to implement the 1997 X.509 Recommendation and RFC 2459. 5) Tested with freeware v1.4 Access Control Library (ACL) that uses SNACC to provide automated access control. SNACC implements the majority of ASN.1 encoding/decoding rules. SNACC does not support all of the latest ASN.1 features, but there are work-arounds that allow SNACC to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1 syntax modules which can be directly compiled using SNACC. The SNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the Enhanced SNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the Enhanced SNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established a SNACC web page . The IMC has also established a SNACC mail list which is used to: distribute information regarding SNACC releases; discuss SNACC-related issues; and provide a means for SNACC users to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We welcome all feedback regarding the Enhanced SNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This SNACC release announcement was sent to several mail lists, but please send all messages regarding the Enhanced SNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the Enhanced SNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, john.pawling@getronicsgov.com Getronics Government Solutions, LLC =========================================== From owner-imc-snacc Tue Nov 21 08:40:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25822 for imc-snacc-bks; Tue, 21 Nov 2000 08:40:32 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25818 for ; Tue, 21 Nov 2000 08:40:30 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 11:40:53 -0500 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B18CA@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: SFL/CML/ACL/Enhanced SNACC Freeware Availability Date: Tue, 21 Nov 2000 11:40:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, The freeware Certificate Management Library (CML), S/MIME Freeware Library (SFL), Access Control Library (ACL) and Enhanced SNACC ASN.1 freeware are no longer available from the web site. They will be available on the Getronics Government Solutions web site by 1 December 2000. I will inform everyone as soon as they are available. They will continue to be freely available to everyone. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== From owner-imc-snacc Tue Dec 5 11:43:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA17003 for imc-snacc-bks; Tue, 5 Dec 2000 11:43:58 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16995 for ; Tue, 5 Dec 2000 11:43:57 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 14:30:05 -0500 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B19DC@wfhqex01.wangfed.com> From: "Pawling, John" To: "Pawling, John" Subject: SFL/CML/ACL/SNACC Freeware Available *NEW CML RELEASE* Date: Tue, 5 Dec 2000 14:30:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, The freeware Certificate Management Library (CML), S/MIME Freeware Library (SFL), Access Control Library (ACL), Enhanced SNACC ASN.1 freeware and Cryptographic Token Interface Libraries (CTIL) developed by Getronics Government Solutions are now available from the following web pages: SFL and CTILs: CML: ACL: Enhanced SNACC ASN.1 Freeware: **NEW CML RELEASE**: The CML files available from are a new release. The v1.81 CML release fixes bugs in the v1.8 CML as documented in the v1.8 CML Problem Report file. With the exception of the CML files, there are no significant differences between the files available from the Getronics Government Solutions web pages and those that were formerly available from the Fortezza Developers Web Site . We welcome all feedback regarding these freeware security libraries. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== From owner-imc-snacc Fri Dec 15 14:37:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18783 for imc-snacc-bks; Fri, 15 Dec 2000 14:37:28 -0800 (PST) Received: from mtk-mail1.mitretek.org (mtk-mail1.mitretek.org [206.241.50.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18779 for ; Fri, 15 Dec 2000 14:37:27 -0800 (PST) Received: from tsfsrv.mitretek.org (root@tsfsrv.mitretek.org [206.241.167.1]) by mtk-mail1.mitretek.org (8.9.3/8.9.3) with ESMTP id RAA28772 for ; Fri, 15 Dec 2000 17:39:48 -0500 (EST) Received: from localhost (stillson@localhost [127.0.0.1]) by tsfsrv.mitretek.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id RAA13091 for ; Fri, 15 Dec 2000 17:23:50 -0500 Date: Fri, 15 Dec 2000 17:23:49 -0500 (EST) From: Ken Stillson To: imc-snacc@imc.org Subject: problems compiling PKIX with ver 1.3b4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi.. I've been having problems compiling the 1998 ASN files from RFC 2459 (appendix B.1 & B.2), which the vda SNACC homepage [http://www.getronicsgov.com/hot/snacc_home.htm] specifically says "can be directly compiled using SNACC" SNACC generates output without any warnings, but the code it generates contains garbage. Here's a snippit of the SNACC generated PKIX1Explicit88.h: === class ExtendedNetworkAddressSeq: public AsnType { public: (null) number; (null) sub_address; === Obviously something has gone wrong. I think these (null)'s are suppsed to be NumericString's. (I tried manually replacing them, but it led to all sorts of other issues.) btw- the commands that led up to this were: .../bin/snacc -C -u .../snacc/asn1/asn-useful.asn1 PKIX1Explicit88.asn1 ln -s PKIX1Explicit88.C PKIX1Explicit88.cc g++ -g -Wconversion -Wall -I...snacc/include/snacc/c++ -Wno-unused -I -o o/PKIX1Explicit88.o -c PKIX1Explicit88.cc Has anyone else been successful in compiling PKIX ? Any thoughts on what might be wrong? Thank you very much! - Ken Stillson -- | Ken Stillson | stillson@mitretek.org | | Sr. Principal Engineer | voice: (703) 610-2965 | | Mitretek Systems | fax: (703) 610-2984 | From owner-imc-snacc Thu Dec 28 07:07:24 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA06169 for imc-snacc-bks; Thu, 28 Dec 2000 07:07:24 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06164 for ; Thu, 28 Dec 2000 07:07:22 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 10:12:29 -0500 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B1AE2@wfhqex01.wangfed.com> From: "Pawling, John" To: imc-snacc@imc.org Subject: FW: problems compiling PKIX with ver 1.3b4 Date: Thu, 28 Dec 2000 10:10:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----Original Message----- From: Colestock, Robert To: 'stillson@mitretek.org'; 'imc-snacc@imc.org' Sent: 12/20/2000 11:45 AM Subject: RE: problems compiling PKIX with ver 1.3b4 Ken: First, I do not know why our homepage says any ASN.1 specification can be encoded without change; I have yet to see a specification that can be directly compiled by SNACC without some modification. Usually this requires simple IMPORTS or the addition of missing definitions if the ASN.1 syntax is too new. I do not believe the SNACC compiler can read 1998 syntax directly (the README tells you). Text from the SNACC/readme.rel file: "Also note that many of the PKIX specs, such as RFC 2459, include 1988- compliant ASN.1 syntax modules which can be directly compiled using SNACC." I assume that the syntax you refer to uses the 1988 definitions. The error you indicate is due to the newest "String" definitions that were moved from the asn-useful.asn1 file to internally supported classes. I have seen this error before, but offhand I do not remember why it occurs (I thought it was fixed permanently). Please check that your command line parameters are similar to the following: SNACCFLAGS = -D -C -VDAexport -u../../../SMPDist/util/VDASnacc/cpplib/asn1/asn-usefulVDA.asn1 as demonstrated in our ./SMIME/libcert/asn1/Make_w32libcertasn make file for MS Windows (same flags on Linux). the "-u" flag would point to the appropriate "asn-usefulVDA.asn1" file relative to your working directory. Also, I need to know which SNACC version you are working with. I assume you are using the C++ version based on the logic below (the "C" compiler builds all of the "String" definitions differently). I also assume that you did not modify the flags in building the SNACC compiler. If you attempt to turn off the "VDADER_RULES" flag, it will disable the special "String" processing. I have not tried to build the compiler with this flag disabled, it is very possible that the "String" logic is broken for the older implementation (I had not intended the library to be used without the "VDADER_RULES" define). IF THIS IS THE CASE (i.e. that you disable the "VDADER_RULES" definition), modify your make references to use the "asn-useful.asn1" file instead of the "asn-usefulVDA.asn1"; this should restore the missing defintions. If you do this, you will lose all of the multi-byte string support that has been added for the different "String" definitions (e.g. PrintableString vs. UTF8String, especially translating between the string types). Our build of the SNACC compiler works fine for all such definitions (we have this specification in our SMIME release). If you still have problems, and your SNACC compiler was built using the default make(s), please send my your version of the ASN.1 specifications; I will attempt to compile it with our current version of the compiler. If this succeeds, I can send you the current (soon to be released) working version of SNACC. Your version should work fine. Another possibility is that you are perhaps linking with an older set of include files? If you had a previous version before loading this version of SNACC, please re-load into a new directory and re-build. This new "String" modification was just made in that release of SNACC. Bob Colestock VDA -----Original Message----- From: Ken Stillson [mailto:stillson@mitretek.org] Sent: Friday, December 15, 2000 5:24 PM To: imc-snacc@imc.org Subject: problems compiling PKIX with ver 1.3b4 Hi.. I've been having problems compiling the 1998 ASN files from RFC 2459 (appendix B.1 & B.2), which the vda SNACC homepage [http://www.getronicsgov.com/hot/snacc_home.htm] specifically says "can be directly compiled using SNACC" SNACC generates output without any warnings, but the code it generates contains garbage. Here's a snippit of the SNACC generated PKIX1Explicit88.h: === class ExtendedNetworkAddressSeq: public AsnType { public: (null) number; (null) sub_address; === Obviously something has gone wrong. I think these (null)'s are suppsed to be NumericString's. (I tried manually replacing them, but it led to all sorts of other issues.) btw- the commands that led up to this were: .../bin/snacc -C -u .../snacc/asn1/asn-useful.asn1 PKIX1Explicit88.asn1 ln -s PKIX1Explicit88.C PKIX1Explicit88.cc g++ -g -Wconversion -Wall -I...snacc/include/snacc/c++ -Wno-unused -I -o o/PKIX1Explicit88.o -c PKIX1Explicit88.cc Has anyone else been successful in compiling PKIX ? Any thoughts on what might be wrong? Thank you very much! - Ken Stillson -- | Ken Stillson | stillson@mitretek.org | | Sr. Principal Engineer | voice: (703) 610-2965 | | Mitretek Systems | fax: (703) 610-2984 | From owner-imc-snacc Thu Jan 4 13:37:28 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA11803 for imc-snacc-bks; Thu, 4 Jan 2001 13:37:28 -0800 (PST) Received: from mtk-mail1.mitretek.org (mtk-mail1.mitretek.org [206.241.50.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11799 for ; Thu, 4 Jan 2001 13:37:27 -0800 (PST) Received: from tsfsrv.mitretek.org (root@tsfsrv.mitretek.org [206.241.167.1]) by mtk-mail1.mitretek.org (8.9.3/8.9.3) with ESMTP id QAA27564; Thu, 4 Jan 2001 16:41:29 -0500 (EST) Received: from localhost (stillson@localhost [127.0.0.1]) by tsfsrv.mitretek.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA03195; Thu, 4 Jan 2001 16:21:18 -0500 Date: Thu, 4 Jan 2001 16:21:14 -0500 (EST) From: Ken Stillson To: "Colestock, Robert" cc: "'imc-snacc@imc.org'" Subject: RE: problems compiling PKIX with ver 1.3b4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Success! What I had not understood is that -DVADER_RULES must not only be defined during the compilation of SNACC itself, but must also be defined when compiling code generated by SNACC. (It turns out that #ifdef VADER_RULES is checked by various things in the SNACC include files). This is what was leading to all sorts of necessary classes not being defined. Thanks for your assistance! Things appear to be working fine now. - Ken -- | Ken Stillson | stillson@mitretek.org | | Sr. Principal Engineer | voice: (703) 610-2965 | | Mitretek Systems | fax: (703) 610-2984 | From owner-imc-snacc Mon Feb 12 02:30:04 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id CAA10673 for imc-snacc-bks; Mon, 12 Feb 2001 02:30:04 -0800 (PST) Received: from softamed.nl (a213-84-17-138.adsl.xs4all.nl [213.84.17.138]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA10668 for ; Mon, 12 Feb 2001 02:30:01 -0800 (PST) Received: from Spooler by softamed.nl (Mercury/32 v3.01a) ID MO001928; 12 Feb 01 11:31:33 +0100 Received: from spooler by softamed.nl (Mercury/32 v3.01a); 12 Feb 01 11:31:27 +0100 Received: from softamed.SoftaNet (192.168.0.2) by Softamed SMTP Server (Mercury/32 v3.01a) with ESMTP ID MG001927; 12 Feb 01 11:31:27 +0100 Received: by SOFTAMED with Internet Mail Service (5.5.2650.21) id <1LDMQ6YM>; Mon, 12 Feb 2001 11:38:33 +0100 Message-ID: <51734B4BA43FD311960A00105A2DF7CE055DD4@SOFTAMED> From: Jaap de Wolff To: "'imc-snacc@imc.org'" Subject: Problems with the snacc compiler. Date: Mon, 12 Feb 2001 11:38:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I am new to ASN.1 and new to snacc. As company we decided recently to use the ASN.1 notation as the way to document our protocols. So I downloaded the snacc sources (v 1.3b4), and compiled them. I am using it under windows NT4.0. And I discovered a few problems: 1- I can't find the commandline switch -D documented. 2- The file "asn-any.h" in c++-lib/inc/ contains: class SNACCDLL_API AsnAny: public AsnType { .... #ifdef VDADER_RULES ~AsnAny(); AsnAny &operator = (const AsnAny &o); }; // AnyDefinedBy is currently the same as AsnAny: typedef AsnAny AsnAnyDefinedBy; #endif /* conditional include */ now if VDADER_RULES is _not_ defined, the class AsnAny has no end. I think the last lines should be: }; // AnyDefinedBy is currently the same as AsnAny: typedef AsnAny AsnAnyDefinedBy; #else }; #endif /* conditional include */ 3- When creating C++ files, those files include "asn-incl.h", which includes the file "snacc.h", also a lot of the files which are included in this file include "snacc.h". I think the created files should _not_ be dependend on snacc.h, but only on files in the c++-lib/inc/ directory. 4- The current release is for the c++ part does (in asn-config.h): #include #include #include #include #include #include ... #ifdef VDADER_RULES //namespace std #ifndef WIN32 #include #else #include #endif #include however according to the ANSI C++ guidelines we should use: #include #include #include #include #include using namespace "std" #ifdef VDADER_RULES //namespace std #include #include from the STL. specialy the microsoft iostream.h can give a lot of trouble, when deriving your own streams, and is a standard. 5- Compiling for C++ crashes if no 'useful types' are given. The same asn.1 module is generating correct c code. In the function TypeLinkBasicType() in line 696 there is a lookup of useful types. This generates a 'Access Violation' if usefulTypeModG == NULL. I think the solution should be always creating the usefulTypeModG, also if no useful types are given. 6- The following piece of code generates the error file "demo.asn", line 6: parse error at symbol "1": Demo { iso(1) ansi(2) usa (3) sfm (4) sseries (5) pdu(6) version (7) } DEFINITIONS ::= BEGIN valtyp-BASE INTEGER ::= 10 -- Scalar types my-define INTEGER ::= valtyp-SCALAR-BASE + 1 END -- of Demo spec 7- The following piece of code generates the error file "demo.asn", line 7: ERROR - tag conflict among the CHOICE elements: Demo { iso(1) ansi(2) usa (3) sfm (4) sseries (5) pdu(6) version (9) } DEFINITIONS ::= BEGIN val1 INTEGER ::= 10 val2 INTEGER ::= 11 ErrDemo ::= SEQUENCE { value CHOICE { valtypINT [val1] IMPLICIT Tint, valtypUINT [val2] IMPLICIT Tuint } } Tint ::= INTEGER (-2147483648 .. 2147483647) Tuint ::= INTEGER (0..4294967295) END -- of Demo spec 8- It is not possible to create tcl code from windows code, with the current project settings. However there is a tcl interpreter for windows (http://dev.scriptics.com/software/tcltk/) What must I do to create a snacc version that supports tcl ? That was it for now. Of course I am willing to cooperate in changing code. --- Jaap de Wolff Wolff@softamed.nl Softamed Nederland B.V. Calandstraat 44 3316 EA Dordrecht Tel. 078 6548787 Fax 078 6548788 www.Softamed.nl From owner-imc-snacc Tue Feb 13 03:59:18 2001 Received: by above.proper.com (8.9.3/8.9.3) id DAA26086 for imc-snacc-bks; Tue, 13 Feb 2001 03:59:18 -0800 (PST) Received: from smtp.circle.net (smtp.circle.net [209.95.64.26]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA26082 for ; Tue, 13 Feb 2001 03:59:17 -0800 (PST) Received: from ca-ol-sqy-13-233.abo.wanadoo.fr ([213.56.236.233] helo=les4y.net ident=root) by smtp.circle.net with esmtp (Exim 2.10 #2) id 14Se70-000BhC-00 for imc-snacc@imc.org; Tue, 13 Feb 2001 11:59:15 +0000 Message-ID: <3A8920E0.B44BAD2F@les4y.net> Date: Tue, 13 Feb 2001 12:56:16 +0100 From: Patrick Duplouy X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-15mdk i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: "'imc-snacc@imc.org'" Subject: Installation problem with the snacc compiler Content-Type: multipart/alternative; boundary="------------429438A9DC09939C0CBC8A61" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --------------429438A9DC09939C0CBC8A61 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I'm really new in ASN.1 and, of course with the snacc compiler. I hope to use ASN for developping PKI-X package, (thanks to getronics for the already existing code) and specially for the RFC 2511 PKI message. My problem is quite simple: I'm runnig a Linux system, base on SuSe distribution. The C compiler is gcc 2.95.2, tcl is 8.3. The compilation works withiut no problem, but when I try to compile some examples programs, e.g. simple, I receive the following errors: p-rec.h:45: syntax error before ; (the ChoiceUnion seems not be defined) dateOfBirth and dateOfHire has incomplete type the ChildInformation::Print generated routine have a bad generated line: if (??? (name)) { Can you help me, what is the mistake I make when compiling snacc Thanks for your help Best regards, Patrick -- Patrick Duplouy pduplouy@les4y.net --------------429438A9DC09939C0CBC8A61 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

I'm really new in ASN.1 and, of course with the snacc compiler. I hope to use ASN for developping PKI-X package, (thanks to getronics for the already existing code) and specially for the RFC 2511 PKI message.

My problem is quite simple:

I'm runnig a Linux system, base on SuSe distribution. The C compiler is gcc 2.95.2, tcl is 8.3.

The compilation works withiut no problem, but when I try to compile some examples programs, e.g. simple, I receive the following errors:

p-rec.h:45: syntax error before ; (the ChoiceUnion seems not be defined)
dateOfBirth and dateOfHire has incomplete type

the ChildInformation::Print generated routine have a bad generated line: if (??? (name)) {

Can you help me, what is the mistake I make when compiling snacc

Thanks for your help

Best regards,
Patrick

-- 
Patrick Duplouy
pduplouy@les4y.net
  --------------429438A9DC09939C0CBC8A61-- From owner-imc-snacc Tue Feb 13 07:22:44 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA09334 for imc-snacc-bks; Tue, 13 Feb 2001 07:22:44 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA09329 for ; Tue, 13 Feb 2001 07:22:43 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Feb 2001 10:26:01 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EC1E@wfhqex06.gfgsi.com> From: "Pawling, John" To: imc-snacc@imc.org Subject: FW: Installation problem with the snacc compiler Date: Tue, 13 Feb 2001 10:26:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C095D1.45310D80" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C095D1.45310D80 Content-Type: text/plain; charset="iso-8859-1" Patrick: Your error appear to be due to the lack of those defninitions. You are aware that all necessary definitions must be IMPORTed into the ASN file being compiled. Also, for SNACC, all definitions must be present at the time of compile (e.g. if a definition is IMPORTed, then the IMPORTed definition ASN file must be on the command line along with this ASN file). We do not provide these 2 definitions in SNACC. If you are still having problems, please send me your ASN.1 file(s), I will attempt to compile them (this should be easy and do as you expect). Bob Colestock VDA -----Original Message----- From: Patrick Duplouy [mailto:pduplouy@les4y.net] Sent: Tuesday, February 13, 2001 6:56 AM To: 'imc-snacc@imc.org' Subject: Installation problem with the snacc compiler Hello, I'm really new in ASN.1 and, of course with the snacc compiler. I hope to use ASN for developping PKI-X package, (thanks to getronics for the already existing code) and specially for the RFC 2511 PKI message. My problem is quite simple: I'm runnig a Linux system, base on SuSe distribution. The C compiler is gcc 2.95.2, tcl is 8.3. The compilation works withiut no problem, but when I try to compile some examples programs, e.g. simple, I receive the following errors: p-rec.h:45: syntax error before ; (the ChoiceUnion seems not be defined) dateOfBirth and dateOfHire has incomplete type the ChildInformation::Print generated routine have a bad generated line: if (??? (name)) { Can you help me, what is the mistake I make when compiling snacc Thanks for your help Best regards, Patrick -- Patrick Duplouy pduplouy@les4y.net ------_=_NextPart_001_01C095D1.45310D80 Content-Type: text/html; charset="iso-8859-1"
Patrick:
 
Your error appear to be due to the lack of those defninitions.  You are aware that all necessary definitions must be IMPORTed into the ASN file being compiled.  Also, for SNACC, all definitions must be present at the time of compile (e.g. if a definition is IMPORTed, then the IMPORTed definition ASN file must be on the command line along with this ASN file).  We do not provide these 2 definitions in SNACC.
 
If you are still having problems, please send me your ASN.1 file(s), I will attempt to compile them (this should be easy and do as you expect).
 
Bob Colestock
VDA
 
-----Original Message-----
From: Patrick Duplouy [mailto:pduplouy@les4y.net]
Sent: Tuesday, February 13, 2001 6:56 AM
To: 'imc-snacc@imc.org'
Subject: Installation problem with the snacc compiler

Hello,

I'm really new in ASN.1 and, of course with the snacc compiler. I hope to use ASN for developping PKI-X package, (thanks to getronics for the already existing code) and specially for the RFC 2511 PKI message.

My problem is quite simple:

I'm runnig a Linux system, base on SuSe distribution. The C compiler is gcc 2.95.2, tcl is 8.3.

The compilation works withiut no problem, but when I try to compile some examples programs, e.g. simple, I receive the following errors:

p-rec.h:45: syntax error before ; (the ChoiceUnion seems not be defined)
dateOfBirth and dateOfHire has incomplete type

the ChildInformation::Print generated routine have a bad generated line: if (??? (name)) {

Can you help me, what is the mistake I make when compiling snacc

Thanks for your help

Best regards,
Patrick

-- 
Patrick Duplouy
pduplouy@les4y.net
 
------_=_NextPart_001_01C095D1.45310D80-- From owner-imc-snacc Tue Feb 13 08:22:57 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA15746 for imc-snacc-bks; Tue, 13 Feb 2001 08:22:57 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA15741 for ; Tue, 13 Feb 2001 08:22:55 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Feb 2001 11:26:14 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EC22@wfhqex06.gfgsi.com> From: "Pawling, John" To: imc-snacc@imc.org Subject: FW: Problems with the snacc compiler. Date: Tue, 13 Feb 2001 11:26:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jaap: Sorry to disappoint you, this software was originally produced as part of a graduate student project. We have simply adapted it to our free-ware implementation of the SMIME V3 e-mail specifications (and added ASN.1 DER encoding rules). As with most projects with a limited budget, we patch what we can and only modify what we must. My comments on each of your topics follow. 1. The command line -D switch is in the man pages for g++ for "-Dmacro". 2. This problem was reported earlier; it has been modified in the newest SNACC being released now. WE DO NOT TEST WITH THIS FLAG OFF so use at your own risk. You will not have any DER encoding rules with this flag disabled. Also, the new release pre-defines this flag internally, since this is the only way we test. The ability to turn off the flag is only retained to allow previous users to disable our logic. 3. Unfortuntately "snacc.h" is needed; we simply copy it into the delivery directory for the SNACC C++ run-time includes. This file is common to the c-lib, C++-lib and the SNACC compiler (both the BOOT and run-time compilers). I wish to avoid 2 copies in our release if possible. 4. The streams problem has also been pointed out before; it is on our list (no scheduled date) to fix this for consistency. There is very little logic that actually writes to the streams (only the << override operator I believe). Issue of priorities for us, the SNACC compiler is a small part of the system. I would be willing to incorporate such modifications if you are successful in building MS Windows/Linux ports of a consistent streams update!!!! We would have to incorporate such changes to all of our utilities, etc (which presently work fine, hence you can see why it is a low priority, sorry). I did try changing the stream include references at one time, but it was not obvious why I had include reference problems with the MS Windows Visual Studio and no easy way to build. Also, we now support strstream in our utilities, this would have to port to the new streams definitions. 5. I must admit that I have never run into this situation; I could not imagine not using the asn-useful.asn1 or asn-usefulVDA.asn files, they are quite necessary for useful definitions (especially PrintableString OCTET STRING tag). What would you suggest as a default? We could certainly make the SNACC compiler resiliant to a missing useful definition. 6. AND 7. Unfortunately there are some modifications necessary to the ASN definitions themselves. I consider these minor mods acceptable; usually I comment out the original definitions (like "valtyp-SCALAR-BASE + 1") and make up a new defition (like " valtyp-BASE INTEGER-PLUS-1 ::= 11"). We have been lobbying our customer to pay for us to upgrade the SNACC compiler to a newer ASN.1 specification (beyond the 1988 spec supported by SNACC). For the second failure (7.), you will have to substitute the actual values, not a definiton for the tags (I did not realise it was even valid to specify a tag through a definition): val1 INTEGER ::= 10 val2 INTEGER ::= 11 ... value CHOICE { valtypINT [10 --val1-- ] IMPLICIT Tint, valtypUINT [11 --val2-- ] IMPLICIT Tuint } ... These limitations seem to be a minor penalty for a free DER encoding compiler. 8. Since we do not use the TCL compiler features, this has not been tested, nor defined for MS Windows. The original SNACC compiler was not built on MS Windows; this was my port, since I did not need TCL the defines are not present. For Linux, the original Makefiles are used (with minor mods for some of our changes), the TCL should build and work fine. I have attempted to not strip out any code so that users like yourself can re-establish such features. If you are successful in integrating TCL into the MS Visual C++ projects, I am willing to incorporate such definitions into the baseline for you (as well as any notes you may have that I can add to a readme file for the project, attributable to you of course). As to what to do to produce a TCL compliant version; I would not know, but you should be able to figure it out easily enough through the Makefiles on the Linux. The Makefile (if built on a Linux box with TCL installed, so that the ./configure script builds the feature into the Makefile) should provide any link references and defines necessary. I can send our Linux makes if you are interested. The code would also help (perhaps the manual; there is a section on TCL). I would also suggest that the DER encoding rules may have to be checked for TCL code generation. You will also have problems with ANYs and table lookups of ANYs by OID since this logic was modified for C++. Both are isolated, small sections and should be easy to test/fix; you will have to understand how the compiler works. Much of the DER encoding changes (only 7 extra rules) were added to the compiler to produce code used by the run-time application; these changes could easily be adapted to TCL. Good indepth questions and invetigation into the SNACC compiler. Thank you for taking the time to respond. we are continuing to make improvements to the compiler. If you plan to change code; please use the newest version, this will make it easier on this end to incorporate changes into the baseline. Also, this version has a number of fixes. It should be available within the week on our website http://www.getronicsgov.com/index.cfm; or I can send you a copy now. The test routines have been improved (vdatest.cpp under the c++-examples directory); this would help in TCL integration to demonstrate different features. Bob Colestock VDA -----Original Message----- From: Jaap de Wolff [mailto:wolff@softamed.nl] Sent: Monday, February 12, 2001 5:39 AM To: 'imc-snacc@imc.org' Subject: Problems with the snacc compiler. Hello, I am new to ASN.1 and new to snacc. As company we decided recently to use the ASN.1 notation as the way to document our protocols. So I downloaded the snacc sources (v 1.3b4), and compiled them. I am using it under windows NT4.0. And I discovered a few problems: 1- I can't find the commandline switch -D documented. 2- The file "asn-any.h" in c++-lib/inc/ contains: class SNACCDLL_API AsnAny: public AsnType { .... #ifdef VDADER_RULES ~AsnAny(); AsnAny &operator = (const AsnAny &o); }; // AnyDefinedBy is currently the same as AsnAny: typedef AsnAny AsnAnyDefinedBy; #endif /* conditional include */ now if VDADER_RULES is _not_ defined, the class AsnAny has no end. I think the last lines should be: }; // AnyDefinedBy is currently the same as AsnAny: typedef AsnAny AsnAnyDefinedBy; #else }; #endif /* conditional include */ 3- When creating C++ files, those files include "asn-incl.h", which includes the file "snacc.h", also a lot of the files which are included in this file include "snacc.h". I think the created files should _not_ be dependend on snacc.h, but only on files in the c++-lib/inc/ directory. 4- The current release is for the c++ part does (in asn-config.h): #include #include #include #include #include #include ... #ifdef VDADER_RULES //namespace std #ifndef WIN32 #include #else #include #endif #include however according to the ANSI C++ guidelines we should use: #include #include #include #include #include using namespace "std" #ifdef VDADER_RULES //namespace std #include #include from the STL. specialy the microsoft iostream.h can give a lot of trouble, when deriving your own streams, and is a standard. 5- Compiling for C++ crashes if no 'useful types' are given. The same asn.1 module is generating correct c code. In the function TypeLinkBasicType() in line 696 there is a lookup of useful types. This generates a 'Access Violation' if usefulTypeModG == NULL. I think the solution should be always creating the usefulTypeModG, also if no useful types are given. 6- The following piece of code generates the error file "demo.asn", line 6: parse error at symbol "1": Demo { iso(1) ansi(2) usa (3) sfm (4) sseries (5) pdu(6) version (7) } DEFINITIONS ::= BEGIN valtyp-BASE INTEGER ::= 10 -- Scalar types my-define INTEGER ::= valtyp-SCALAR-BASE + 1 END -- of Demo spec 7- The following piece of code generates the error file "demo.asn", line 7: ERROR - tag conflict among the CHOICE elements: Demo { iso(1) ansi(2) usa (3) sfm (4) sseries (5) pdu(6) version (9) } DEFINITIONS ::= BEGIN val1 INTEGER ::= 10 val2 INTEGER ::= 11 ErrDemo ::= SEQUENCE { value CHOICE { valtypINT [val1] IMPLICIT Tint, valtypUINT [val2] IMPLICIT Tuint } } Tint ::= INTEGER (-2147483648 .. 2147483647) Tuint ::= INTEGER (0..4294967295) END -- of Demo spec 8- It is not possible to create tcl code from windows code, with the current project settings. However there is a tcl interpreter for windows (http://dev.scriptics.com/software/tcltk/) What must I do to create a snacc version that supports tcl ? That was it for now. Of course I am willing to cooperate in changing code. --- Jaap de Wolff Wolff@softamed.nl Softamed Nederland B.V. Calandstraat 44 3316 EA Dordrecht Tel. 078 6548787 Fax 078 6548788 www.Softamed.nl From owner-imc-snacc Tue Feb 13 09:04:17 2001 Received: by above.proper.com (8.9.3/8.9.3) id JAA18239 for imc-snacc-bks; Tue, 13 Feb 2001 09:04:17 -0800 (PST) Received: from softamed.nl (a213-84-17-138.adsl.xs4all.nl [213.84.17.138]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA18232 for ; Tue, 13 Feb 2001 09:04:15 -0800 (PST) Received: from Spooler by softamed.nl (Mercury/32 v3.01a) ID MO000216; 13 Feb 01 18:05:48 +0100 Received: from spooler by softamed.nl (Mercury/32 v3.01a); 13 Feb 01 18:05:32 +0100 Received: from softamed.SoftaNet (192.168.0.2) by Softamed SMTP Server (Mercury/32 v3.01a) with ESMTP ID MG000215; 13 Feb 01 18:05:22 +0100 Received: by SOFTAMED with Internet Mail Service (5.5.2650.21) id <1LDMQ7D8>; Tue, 13 Feb 2001 18:12:51 +0100 Message-ID: <51734B4BA43FD311960A00105A2DF7CE055DDE@SOFTAMED> From: Jaap de Wolff To: "'Colestock, Robert'" Cc: "'imc-snacc@imc.org'" Subject: RE: Problems with the snacc compiler. Date: Tue, 13 Feb 2001 18:12:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: Colestock, Robert [mailto:Robert.Colestock@GetronicsGov.com] > Sent: Tuesday, February 13, 2001 5:10 PM > To: 'wolff@softamed.nl' > Cc: Pawling, John > Subject: RE: Problems with the snacc compiler. > > > Jaap: > > Sorry to disappoint you, this software was originally > produced as part of a > graduate student project. We have simply adapted it to our free-ware > implementation of the SMIME V3 e-mail specifications (and > added ASN.1 DER > encoding rules). As with most projects with a limited > budget, we patch what > we can and only modify what we must. I am not dissappointed, I did expect this. But I thought I best could give all points in one pass, I have no insight in the project, and don't know which points are more, and which less easy to fix. You are right that compiling without usefull types is not useful, and I did find this bug 'by accident'. For me the most important points are point 4 and point 6/7. About point 6/7: I have lots of ASN-code (400K+) which do this kind of things. But maybe I can make a pre-processor to do those things. And the other site: I derive my own streams for years now, and I was happy with the new STL conventions. And because this is only used in the C++ part, it should be easy to change. But that is something I can do myself, and maybe implement I can implement it conditional, so your code can still be used. I will try to do those things. I'm afraid I don't have time for that before you made your release, so it must be added later. You will hear from me. Jaap de Wolff From owner-imc-snacc Fri Feb 16 13:23:50 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA25469 for imc-snacc-bks; Fri, 16 Feb 2001 13:23:50 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25465 for ; Fri, 16 Feb 2001 13:23:49 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Feb 2001 16:27:09 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EC78@wfhqex06.gfgsi.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.3 R5 Enhanced SNACC ASN.1 Freeware Date: Fri, 16 Feb 2001 16:27:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Getronics Government Solutions has delivered the v1.3 R5 Enhanced SNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.7 and Microsoft Windows NT/95/98/2000. The source code and the Enhanced SNACC Software Public License are freely available to everyone from: In past releases, Getronics enhanced the SNACC library to implement the Distinguished Encoding Rules (DER). In the v1.3 R5 SNACC release, Getronics included the following enhancements: 1) Resolved compiler warnings. 2) Enhanced C++ library encode/decode performance. 3) Converted all source code to use CVS configuration management system. 4) Update SNACC readme file. 5) Tested with v1.9 S/MIME Freeware Library (SFL) that uses SNACC to implement the IETF S/MIME v3 set of specifications. 6) Tested with freeware v1.9 Certificate Management Library (CML) that uses SNACC to implement the 2000 X.509 Recommendation and RFC 2459. 7) Tested with freeware v1.5 Access Control Library (ACL) that uses SNACC to provide automated access control. SNACC implements the majority of ASN.1 encoding/decoding rules. SNACC does not support all of the latest ASN.1 features, but there are work-arounds that allow SNACC to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1 syntax modules which can be compiled using SNACC. The SNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the Enhanced SNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the Enhanced SNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established a SNACC web page . The IMC has also established a SNACC mail list which is used to: distribute information regarding SNACC releases; discuss SNACC-related issues; and provide a means for SNACC users to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We welcome all feedback regarding the Enhanced SNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This SNACC release announcement was sent to several mail lists, but please send all messages regarding the Enhanced SNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the Enhanced SNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== From owner-imc-snacc Mon Feb 19 04:18:44 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA01032 for imc-snacc-bks; Mon, 19 Feb 2001 04:18:44 -0800 (PST) Received: from mx7.port.ru (mx7.port.ru [194.67.23.44]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA01028 for ; Mon, 19 Feb 2001 04:18:42 -0800 (PST) Received: from [195.28.33.228] (helo=SLEPPC) by mx7.port.ru with smtp (Exim 3.14 #4) id 14UpH5-0005Ap-00 for imc-snacc@imc.org; Mon, 19 Feb 2001 15:18:39 +0300 Message-ID: <001501c09a6d$c1295c80$LocalHost@SLEPPC> From: "slep" To: Subject: Enhansed SNACC problem Date: Mon, 19 Feb 2001 15:16:13 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01C09A86.E58B9840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C09A86.E58B9840 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01C09A86.E58B9840" ------=_NextPart_001_0012_01C09A86.E58B9840 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hello, We are trying to use the compiler=20 v1.3 R4 Enhansed Snacc for TCAP messages=20 processing (according to Q.773 specification of TCAP protocol).=20 We checks this ASN.1 source by OSS ASN.1 Syntax Checker -=20 input ASN.1 module successfully passed the syntax check. When we running Snacc -c -u <...> in Win98 for Tcapmess.asn1 file, = snacc is crashed. Could you help us? Vadim Slep. ------=_NextPart_001_0012_01C09A86.E58B9840 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
 Hello,

We are trying to use the compiler

v1.3 R4 Enhansed Snacc for TCAP messages

processing (according to Q.773 specification of TCAP = protocol).=20

We checks this ASN.1 source by OSS ASN.1 Syntax = Checker –=20

input ASN.1 module successfully passed the syntax=20 check.

When we running Snacc -c -u <...>  in Win98 = for=20 Tcapmess.asn1 file, snacc is crashed.

Could you help us?

Vadim Slep.

------=_NextPart_001_0012_01C09A86.E58B9840-- ------=_NextPart_000_0011_01C09A86.E58B9840 Content-Type: application/octet-stream; name="Tcapmess.asn1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Tcapmess.asn1" TCAPMess { ccitt recommendation 773 modules (2) messages (1) version2 = (2) } DEFINITIONS ::=3D BEGIN EXPORTS OPERATION, ERROR, Component, InvokeIdType; -- Transaction Portion fields MessageType ::=3D CHOICE { unidirectional [APPLICATION 1] IMPLICIT Unidirectional, begin [APPLICATION 2] IMPLICIT Begin, end [APPLICATION 4] IMPLICIT End, continue [APPLICATION 5] IMPLICIT Continue, abort [APPLICATION 7] IMPLICIT Abort } Unidirectional ::=3D SEQUENCE { dialoguePortion DialoguePortion = OPTIONAL, components ComponentPortion } Begin ::=3D SEQUENCE { otid OrigTransactionID, dialoguePortion DialoguePortion OPTIONAL, components ComponentPortion OPTIONAL } End ::=3D SEQUENCE { dtid DestTransactionID, dialoguePortion DialoguePortion OPTIONAL, components ComponentPortion OPTIONAL } Continue ::=3D SEQUENCE { otid OrigTransactionID, dtid DestTransactionID, dialoguePortion DialoguePortion OPTIONAL, components ComponentPortion OPTIONAL } Abort ::=3D SEQUENCE { dtid DestTransactionID, reason CHOICE { p-abortCause P-AbortCause, dialoguePortion DialoguePortion } OPTIONAL } -- NOTE - When the Abort Message is generated by the Transaction = sub-layer, a p-Abort Cause must be present. --IMPORTS dialogue-as-id, DialoguePDU; --dangerous vadik change!! DialoguePortion ::=3D [APPLICATION 11] [UNIVERSAL 8] IMPLICIT SEQUENCE=20 {dialogue-as-id OBJECT IDENTIFIER, dPDU DialoguePDU } --dialogue-as-id { ccitt recommendation q 773 as (1) dialogue-as (1) = version1 (1) } DialoguePDU ::=3D CHOICE { dialogueRequest AARQ-apdu, dialogueResponse AARE-apdu, dialogueAbort ABRT-apdu } AARQ-apdu ::=3D [0] IMPLICIT SEQUENCE {=20 protocol-version [0] IMPLICIT BIT STRING { version1 (0) } DEFAULT { version1 }, application-context-name [1] = OBJECT IDENTIFIER, user-information [30] IMPLICIT OCTET STRING OPTIONAL } AARE-apdu ::=3D [1] IMPLICIT SEQUENCE { protocol-version [0] IMPLICIT BIT STRING { version1 (0) } DEFAULT { version1 }, application-context-name [1] OBJECT IDENTIFIER, result [2] Associate-result, result-source-diagnostic [3] Associate-source-diagnostic, user-information [30] IMPLICIT OCTET STRING OPTIONAL } -- RLRQ PDU is currently not used. -- It is included for completeness only. RLRQ-apdu ::=3D [2] IMPLICIT SEQUENCE { reason [0] IMPLICIT Release-request-reason OPTIONAL, user-information [30] IMPLICIT OCTET STRING OPTIONAL } -- RLRE PDU is currently not used. -- It is included for completeness only RLRE-apdu ::=3D [APPLICATION 3] IMPLICIT SEQUENCE { reason [0] IMPLICIT Release-response-reason OPTIONAL, user-information [30] IMPLICIT OCTET STRING OPTIONAL } ABRT-apdu ::=3D [4] IMPLICIT SEQUENCE { abort-source [0] IMPLICIT ABRT-source, user-information [30] IMPLICIT OCTET STRING OPTIONAL } ABRT-source ::=3D INTEGER { dialogue-service-user (0), dialogue-service-provider (1) } Associate-result ::=3D INTEGER { accepted (0), reject-permanent (1) } Associate-source-diagnostic ::=3D CHOICE { dialogue-service-user [1] INTEGER { null (0), no-reason-given (1), application-context-name-not-supported (2) }, dialogue-service-provider [2] INTEGER { null (0), no-reason-given (1), no-common-dialogue-portion (2) } } -- Release-request-reason is currently not used. -- It is included for completeness only. Release-request-reason ::=3D INTEGER { normal (0), urgent (1), user-defined (30) } -- Release-response-reason is currently not used.=20 -- It is included for completeness only. Release-response-reason ::=3D INTEGER { normal (0), not-finished (1), user-defined (30) } -- The dialogue portion carries the dialogue control PDUs as value of = the external data type. -- The direct reference should be set to { ccitt recommendation q 773 as = (1) dialogue-as (1) version (1) } -- if structured dialogue is used and to { ccitt recommendation q 773 as = (1) unidialogue-as (2) version (1) } -- if unstructured dialogue is used or any user defined abstract syntax = name when only user information -- is carried (e.g. when user information is sent in a 1988 Abort = message). OrigTransactionID ::=3D [APPLICATION 8] IMPLICIT OCTET STRING (SIZE = (1..4) ) DestTransactionID ::=3D [APPLICATION 9] IMPLICIT OCTET STRING (SIZE = (1..4) ) P-AbortCause ::=3D [APPLICATION 10] IMPLICIT INTEGER { unrecognizedMessageType (0), unrecognizedTransactionID (1), badlyFormattedTransactionPortion (2), incorrectTransactionPortion (3), resourceLimitation (4) } -- COMPONENT PORTION. The last field in the transaction portion of the = TCAP message is the Component Portion. -- The Component Portion may be absent. ComponentPortion ::=3D [APPLICATION 12] IMPLICIT SEQUENCE SIZE (1..MAX) = OF Component -- Component Portion fields -- COMPONENT TYPE. Recommendation X.229 defines four Application = Protocol Data Units (APDUs). -- TCAP adds returnResultNotLast to allow for the segmentation of a = result. Component ::=3D CHOICE { invoke [1] IMPLICIT Invoke, returnResultLast [2] IMPLICIT ReturnResult, returnError [3] IMPLICIT ReturnError, reject [4] IMPLICIT Reject, returnResultNotLast [7] IMPLICIT ReturnResult } -- The Components are sequences of data elements. Invoke ::=3D SEQUENCE { invokeID InvokeIdType, linkedID [0] IMPLICIT InvokeIdType OPTIONAL, operationCode OPERATION, parameter ANY DEFINED BY operationCode OPTIONAL } -- ANY is filled by the single ASN.1 data type following the keyword = PARAMETER or the keyword ARGUMENT -- in the type definition of a particular operation. ReturnResult ::=3D SEQUENCE { invokeID InvokeIdType, result SEQUENCE { operationCode OPERATION, parameter ANY DEFINED BY operationCode=20 } OPTIONAL } -- ANY is filled by the single ASN.1 datatype following the keyword = RESULT in the type definition -- of a particular operation. ReturnError ::=3D SEQUENCE { invokeID InvokeIdType, errorCode ERROR, parameter ANY DEFINED BY errorCode OPTIONAL } -- ANY is filled by the single ASN.1 data type following the keyword = PARAMETER in the type definition -- of a particular error. Reject ::=3D SEQUENCE { invokeID CHOICE {=09 derivable InvokeIdType, not-derivable NULL }, problem CHOICE { generalProblem [0] IMPLICIT GeneralProblem, invokeProblem [1] IMPLICIT InvokeProblem, returnResultProblem [2] IMPLICIT ReturnResultProblem, returnErrorProblem [3] IMPLICIT ReturnErrorProblem } } InvokeIdType ::=3D INTEGER (-128..127) -- PROBLEMS GeneralProblem ::=3D INTEGER { unrecognizedComponent (0), mistypedComponent (1), badlyStructuredComponent (2) } InvokeProblem ::=3D INTEGER { duplicateInvokeID (0), unrecognizedOperation (1), mistypedParameter (2), resourceLimitation (3), initiatingRelease (4), unrecognizedLinkedID (5), linkedResponseUnexpected (6), unexpectedLinkedOperation (7) } ReturnResultProblem ::=3D INTEGER { unrecognizedInvokeID (0), returnResultUnexpected (1), mistypedParameter (2) } ReturnErrorProblem ::=3D INTEGER { unrecognizedInvokeID (0), returnErrorUnexpected (1), unrecognizedError (2), unexpectedError (3), mistypedParameter (4) } -- OPERATIONS -- Operations are specified with the OPERATION MACRO. -- When an operation is specified, the valid parameter set, results, and = errors for that operation are indicated. -- Default values and optional parameters are permitted. OPERATION MACRO ::=3D BEGIN TYPE NOTATION ::=3D Parameter Result Errors LinkedOperations VALUE NOTATION ::=3D value (VALUE CHOICE { localValue INTEGER } ) -- ,globalValue OBJECT IDENTIFIER } ) Parameter ::=3D ArgKeyword NamedType | empty ArgKeyword ::=3D "ARGUMENT" | "PARAMETER" Result ::=3D "RESULT" ResultType | empty Errors ::=3D "ERRORS" "{"ErrorNames"}" | empty LinkedOperations ::=3D "LINKED" "{"LinkedOperationNames"}" | empty ResultType ::=3D NamedType | empty ErrorNames ::=3D ErrorList | empty ErrorList ::=3D Error | ErrorList "," Error Error ::=3D value (ERROR) -- shall reference an error value | type -- shall reference an error type -- if no error value is specified LinkedOperationNames ::=3D OperationList | empty OperationList ::=3D Operation | OperationList "," Operation Operation ::=3D value (OPERATION) -- shall reference an operation value | type -- shall reference an operation type if -- no operation value is specified NamedType ::=3D identifier type | type END -- ERRORS -- Errors are specified with the ERROR MACRO. -- When an error is specified, the valid parameters for that error are = indicated. -- Default values and optional parameters are permitted. ERROR MACRO ::=3D BEGIN TYPE NOTATION ::=3D Parameter VALUE NOTATION ::=3D value (VALUE CHOICE { localValue INTEGER } ) -- ,globalValue OBJECT IDENTIFIER } ) Parameter ::=3D "PARAMETER" NamedType | empty NamedType ::=3D identifier type | type END END -- TCAPMessages ------=_NextPart_000_0011_01C09A86.E58B9840-- From owner-imc-snacc Tue Feb 27 11:24:57 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA13072 for imc-snacc-bks; Tue, 27 Feb 2001 11:24:57 -0800 (PST) Received: from mail.motus.qc.ca (mail.motus.qc.ca [207.236.155.221]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA13068 for ; Tue, 27 Feb 2001 11:24:55 -0800 (PST) From: eboudreault@motus.com Subject: To: imc-snacc@imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 27 Feb 2001 14:25:09 -0500 X-MIMETrack: Serialize by Router on motus1/Motus Technologies Inc.(Release 5.0.5 |September 22, 2000) at 2001-02-27 14:25:42 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA13069 Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I don't understand what i have to fix and why tag0 is not used. Somebody can help me ???? void AttributeTypeAndDistinguishedValueSetOfSeq::BDecContent (BUF_TYPE b, AsnTag /*tag0*/, AsnLen elmtLen0, AsnLen &bytesDecoded, ENV_TYPE env) { AsnTag tag1; AsnLen seqBytesDecoded = 0; AsnLen elmtLen1; <------------------------------------------------- ????? // ANY type <------------------------------------------------- ????? distingAttrValue = new AsnAny; DEC_LOAD_ANYBUF(distingAttrValue, b, seqBytesDecoded, env); tag1 = BDecTag (b, seqBytesDecoded, env); if ((tag1 == MAKE_TAG_ID (UNIV, CONS, SET_TAG_CODE))) { elmtLen1 = BDecLen (b, seqBytesDecoded, env); contextList.BDecContent (b, tag1, elmtLen1, seqBytesDecoded, env); } else { Asn1Error << "ERROR - SEQUENCE is missing non-optional elmt." << endl; longjmp (env, -108); } bytesDecoded += seqBytesDecoded; if (elmtLen0 == INDEFINITE_LEN) { BDecEoc (b, bytesDecoded, env); return; } else if (seqBytesDecoded != elmtLen0) { Asn1Error << "ERROR - Length discrepancy on sequence." << endl; longjmp (env, -109); } else return; } // AttributeTypeAndDistinguishedValueSetOfSeq::BDecContent Thanks . ********************************************************************************************** Eric Boudreault ------------------------------------------------ Programmeur ------------------------------------------------ Motus Technologies 390, St-Vallier Est Bureau 100 Québec, Qc G1K 3P6 Tél.: 521-2100 ext.#242 Fax.: 521-2101 courriel: eboudreault@motus.com ********************************************************************************************** From owner-imc-snacc Tue Feb 27 13:51:34 2001 Received: by above.proper.com (8.9.3/8.9.3) id NAA21298 for imc-snacc-bks; Tue, 27 Feb 2001 13:51:34 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA21293 for ; Tue, 27 Feb 2001 13:51:33 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 16:54:51 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945ECEC@wfhqex06.gfgsi.com> From: "Pawling, John" To: imc-snacc@imc.org Subject: FW: Date: Tue, 27 Feb 2001 16:54:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA21294 Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----Original Message----- From: Colestock, Robert Sent: Tuesday, February 27, 2001 3:33 PM To: 'eboudreault@motus.com' Cc: Pawling, John Subject: RE: eboudreault: I cannot tell why the SNACC compiler wrote the code in this manner; please send me the ASN.1 excerpt that caused this error. I suspect it is due to a confusion in a Sequence, Sequence of, Set or Set of with other Anys. I have found that OPTIONAL elements sometimes cause ambiguous(?) decodings, causing such an error. This should have been indicated at the SNACC copilation level before the .C code was output. What you have to fix is to tag the ANY (e.g. [3]) so that the SNACC compiler can correctly recognize the OPTIONAL Any if present. You must have other definitions that confuse the decoding process since an ANY can be any ASN.1 type (e.g. in a Sequence). Bob Colestock VDA -----Original Message----- From: eboudreault@motus.com [mailto:eboudreault@motus.com] Sent: Tuesday, February 27, 2001 2:25 PM To: imc-snacc@imc.org Subject: Hi, I don't understand what i have to fix and why tag0 is not used. Somebody can help me ???? void AttributeTypeAndDistinguishedValueSetOfSeq::BDecContent (BUF_TYPE b, AsnTag /*tag0*/, AsnLen elmtLen0, AsnLen &bytesDecoded, ENV_TYPE env) { AsnTag tag1; AsnLen seqBytesDecoded = 0; AsnLen elmtLen1; <------------------------------------------------- ????? // ANY type <------------------------------------------------- ????? distingAttrValue = new AsnAny; DEC_LOAD_ANYBUF(distingAttrValue, b, seqBytesDecoded, env); tag1 = BDecTag (b, seqBytesDecoded, env); if ((tag1 == MAKE_TAG_ID (UNIV, CONS, SET_TAG_CODE))) { elmtLen1 = BDecLen (b, seqBytesDecoded, env); contextList.BDecContent (b, tag1, elmtLen1, seqBytesDecoded, env); } else { Asn1Error << "ERROR - SEQUENCE is missing non-optional elmt." << endl; longjmp (env, -108); } bytesDecoded += seqBytesDecoded; if (elmtLen0 == INDEFINITE_LEN) { BDecEoc (b, bytesDecoded, env); return; } else if (seqBytesDecoded != elmtLen0) { Asn1Error << "ERROR - Length discrepancy on sequence." << endl; longjmp (env, -109); } else return; } // AttributeTypeAndDistinguishedValueSetOfSeq::BDecContent Thanks . **************************************************************************** ****************** Eric Boudreault ------------------------------------------------ Programmeur ------------------------------------------------ Motus Technologies 390, St-Vallier Est Bureau 100 Québec, Qc G1K 3P6 Tél.: 521-2100 ext.#242 Fax.: 521-2101 courriel: eboudreault@motus.com **************************************************************************** ****************** From owner-imc-snacc Fri Mar 23 03:31:01 2001 Received: by above.proper.com (8.9.3/8.9.3) id DAA00608 for imc-snacc-bks; Fri, 23 Mar 2001 03:31:01 -0800 (PST) Received: from ntserver.hps.co.ma ([212.217.52.196]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA00602 for ; Fri, 23 Mar 2001 03:30:57 -0800 (PST) Received: from faycal.hps.co.ma ([192.42.172.82]) by ntserver.hps.co.ma (Netscape Messaging Server 3.5) with SMTP id 226 for ; Fri, 23 Mar 2001 11:27:18 +0000 Received: by localhost with Microsoft MAPI; Fri, 23 Mar 2001 11:32:05 -0000 Message-ID: <01C0B38C.E30F54C0.elmotie@hps.co.ma> From: "rachid elmotie" To: "'imc-snacc@imc.org'" Subject: Snacc error Date: Fri, 23 Mar 2001 11:32:03 -0000 Organization: hps X-Mailer: Messagerie Internet de Microsoft/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello I have installed the Snacc in my computer, so i have encountred a greet probleme when i tried to compile " test-lib.c " . so the generated error was : : \c-lib\inc\asn-config.h(219) : fatal error C1189: #error : " don't know what buffer type to use! " i want just to say that the same error is generated when i compile others examples. So, please if you have any solution to resolve this probleme, make me informed. Best regards From owner-imc-snacc Fri Mar 23 06:41:30 2001 Received: by above.proper.com (8.9.3/8.9.3) id GAA14541 for imc-snacc-bks; Fri, 23 Mar 2001 06:41:30 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA14535 for ; Fri, 23 Mar 2001 06:41:29 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Mar 2001 09:41:45 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EEC8@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'rachid elmotie'" , "'imc-snacc@imc.org'" Subject: RE: Snacc error Date: Fri, 23 Mar 2001 09:41:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----Original Message----- From: Colestock, Robert Sent: Thursday, March 22, 2001 5:02 PM To: 'elmotie@hps.co.ma' Cc: Pawling, John Subject: RE: Snacc rachid: Sorry, we only use the C++ side of the SNACC compiler. We have been updating some portions of the "C" library, but I do not keep up with the "C" test program(s). This particular error has to do with the buffer choice, the old SNACC manual describes some of the choices you must make (through the command line "-D" or compiler define) in order to specify which buffer scheme to use. In C++ there was only 1 choice and no flags. The project or makefile should have indicated a choice for this particular test. Our release has a copy of the old SNACC manual in ./SNACC/doc/snacc-a5.ps (postscript). I can send you a .pdf copy if you are interested. After looking at the test-lib makefile, it specifies "-DUSE_SBUF" (which is the most common buffer). You should use this flag on any files that include the "C" SNACC includes. Bob Colestock VDA -----Original Message----- From: rachid elmotie [mailto:elmotie@hps.co.ma] Sent: Friday, March 23, 2001 6:32 AM To: 'imc-snacc@imc.org' Subject: Snacc error Hello I have installed the Snacc in my computer, so i have encountred a greet probleme when i tried to compile " test-lib.c " . so the generated error was : : \c-lib\inc\asn-config.h(219) : fatal error C1189: #error : " don't know what buffer type to use! " i want just to say that the same error is generated when i compile others examples. So, please if you have any solution to resolve this probleme, make me informed. Best regards From owner-imc-snacc Tue Apr 24 13:49:53 2001 Received: by above.proper.com (8.9.3/8.9.3) id NAA18311 for imc-snacc-bks; Tue, 24 Apr 2001 13:49:53 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA18303 for ; Tue, 24 Apr 2001 13:49:51 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Apr 2001 16:50:38 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259692A92@wfhqex06.gfgsi.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.3 R6 Enhanced SNACC ASN.1 Freeware Date: Tue, 24 Apr 2001 16:50:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Getronics Government Solutions has delivered the v1.3 R6 Enhanced SNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.7 and Microsoft Windows NT/98/2000. The source code and the Enhanced SNACC Software Public License are freely available to everyone from: In past releases, Getronics enhanced the SNACC library to implement the Distinguished Encoding Rules (DER). In the v1.3 R6 SNACC release, Getronics included the following enhancements: 1) Fixes bugs in SNACC C Library regarding the handling of multi-byte characters. 2) Tested with v1.10 S/MIME Freeware Library (SFL) that uses SNACC to implement the IETF S/MIME v3 set of specifications. 3) Tested with freeware v1.9.1 Certificate Management Library (CML) that uses SNACC to implement the 2000 X.509 Recommendation and RFC 2459. 4) Tested with freeware v1.5 Access Control Library (ACL) that uses SNACC to provide automated access control. SNACC implements the majority of ASN.1 encoding/decoding rules. SNACC does not support all of the latest ASN.1 features, but there are work-arounds that allow SNACC to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1 syntax modules which can be compiled using SNACC. The SNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the Enhanced SNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the Enhanced SNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established a SNACC web page . The IMC has also established a SNACC mail list which is used to: distribute information regarding SNACC releases; discuss SNACC-related issues; and provide a means for SNACC users to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We welcome all feedback regarding the Enhanced SNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This SNACC release announcement was sent to several mail lists, but please send all messages regarding the Enhanced SNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the Enhanced SNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== From owner-imc-snacc Thu Apr 26 11:40:47 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA06652 for imc-snacc-bks; Thu, 26 Apr 2001 11:40:47 -0700 (PDT) Received: from mtk-mail1.mitretek.org (mtk-mail1.mitretek.org [206.241.50.65]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA06648 for ; Thu, 26 Apr 2001 11:40:46 -0700 (PDT) From: kds@mitretek.org Received: from mail1.mitretek.org (mail1.mitretek.org [172.16.49.31]) by mtk-mail1.mitretek.org (8.9.3+Sun/8.9.3) with ESMTP id OAA24207 for ; Thu, 26 Apr 2001 14:40:17 -0400 (EDT) Received: from tsfsrv.mitretek.org ([206.241.167.1]) by mail1.mitretek.org (Lotus Domino Release 5.0.4) with ESMTP id 2001042614401650:15404 ; Thu, 26 Apr 2001 14:40:16 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost (8.12.0.Beta5/8.12.0.Beta5/Debian 8.12.0-1) with ESMTP id f3QIiV3j005494 for ; Thu, 26 Apr 2001 14:44:35 -0400 Date: Thu, 26 Apr 2001 14:44:30 -0400 (EDT) X-X-Sender: Reply-To: To: Subject: SNACC integer size too small for PKI ? Message-ID: MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on Mail1/Mitretek Systems(Release 5.0.4 |June 8, 2000) at 04/26/2001 02:40:16 PM, Serialize by Router on Mail1/Mitretek Systems(Release 5.0.4 |June 8, 2000) at 04/26/2001 02:40:17 PM, Serialize complete at 04/26/2001 02:40:17 PM Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hey. Quick question for whoever out there can help... Various PKI structures, such as X509 certificates (field: certificateSerialNumber), contain fields of asn.1 type "INTEGER" In common usage, these serial numbers tend to be very large (16 bytes or so), but SNACC appears to be have its internal type AsnIntType tied to 32 bit intereger. So- I'm having problems getting SNACC to create or parse just about anything PKI related. I get AsnInt::BDecContent: ERROR - integer is too big to decode when I try to decode, and cannot find any method to allow me to load the internal AsnInt state to a large value to try and encode. Is there some other SNACC type I should be using? (LONG INTEGER doesn't appear to parse.) Should I try to trick SNACC by creating my own pre-compiled code type that mimics "OCTET STRING" but changes the TAG to "UNIV,PRIM,INTEGER_TAG_CODE" ? Any ideas would be most appreicated! - Ken Stillson, kds@mitretek.org -- | Ken Stillson | stillson@mitretek.org | | Sr. Principal Engineer | voice: (703) 610-2965 | | Mitretek Systems | fax: (703) 610-2984 | From owner-imc-snacc Thu Apr 26 12:10:29 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA07219 for imc-snacc-bks; Thu, 26 Apr 2001 12:10:29 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA07215 for ; Thu, 26 Apr 2001 12:10:27 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Apr 2001 15:11:25 -0400 Message-ID: <0B95FB5619B3D411817E006008A592592C2DE2@wfhqex06.gfgsi.com> From: "Nicholas, Richard" To: imc-snacc@imc.org Subject: RE: SNACC integer size too small for PKI ? Date: Thu, 26 Apr 2001 15:11:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ken, In the Certificate Management Library we wrote for the U.S. DoD, we changed the ASN.1 definitions for the productions containing large INTEGERs similar to the following example from X.509: CertificateSerialNumber ::= [UNIVERSAL 2] IMPLICIT OCTET STRING -- originally INTEGER SNACC would then correctly generate encoding/decoding functions to handle those large ASN.1 INTEGERs, by treating them as OCTET STRINGs, which they essentially are. This solution does require you to modify the ASN.1 syntax and you must be able to anticipate ahead of time which INTEGERs need this mod. The best solution is to modify the SNACC library to handle INTEGERs larger than a 32-bit integer. I believe that is one of the proposed changes to be included in the next release of the Getronics SNACC code. I think that version is scheduled for release in late July. - Rich --------------------------- Richard E. Nicholas Principal Secure Systems Engineer Getronics Government Solutions, LLC Richard.Nicholas@GetronicsGov.com (301) 939-2722 > -----Original Message----- > From: kds@mitretek.org [mailto:kds@mitretek.org] > Sent: Thursday, April 26, 2001 2:45 PM > To: imc-snacc@imc.org > Subject: SNACC integer size too small for PKI ? > > > > Hey. Quick question for whoever out there can help... > > Various PKI structures, such as X509 certificates (field: > certificateSerialNumber), contain fields of asn.1 type "INTEGER" > > In common usage, these serial numbers tend to be very large > (16 bytes or > so), but SNACC appears to be have its internal type > AsnIntType tied to 32 > bit intereger. > > So- I'm having problems getting SNACC to create or parse just about > anything PKI related. I get > AsnInt::BDecContent: ERROR - integer is too big to decode > when I try to decode, and cannot find any method to allow > me to load the > internal AsnInt state to a large value to try and encode. > > Is there some other SNACC type I should be using? > (LONG INTEGER doesn't appear to parse.) > > Should I try to trick SNACC by creating my own pre-compiled > code type that > mimics "OCTET STRING" but changes the TAG to > "UNIV,PRIM,INTEGER_TAG_CODE" ? > > Any ideas would be most appreicated! > > - Ken Stillson, > kds@mitretek.org > > -- > | Ken Stillson | stillson@mitretek.org | > | Sr. Principal Engineer | voice: (703) 610-2965 | > | Mitretek Systems | fax: (703) 610-2984 | From owner-imc-snacc Thu Apr 26 12:21:03 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA07395 for imc-snacc-bks; Thu, 26 Apr 2001 12:21:03 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA07391 for ; Thu, 26 Apr 2001 12:21:02 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Apr 2001 15:22:00 -0400 Message-ID: From: "Colestock, Robert" To: "'kds@mitretek.org'" Cc: "Pawling, John" , "'imc-snacc@imc.org'" Subject: RE: SNACC integer size too small for PKI ? Date: Thu, 26 Apr 2001 15:21:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-imc-snacc@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ken: That is exactly what we do. We create a special BigIntegerString definition with the integer tag and treat it as an Octet String. You must redefine the ASN.1 defintion to use this new definition. The syntax is below: BigIntegerStr ::= [UNIVERSAL 2] IMPLICIT OCTET STRING Sorry, we have this fixed in our application, but have not moved it to SNACC (yet). We have a bucket of functionality that supplements this class to handle the 0 extension of (negative) integers that follow the big integer rules for signature processing, if this is of interest to you. This is only an issue if you try to place binary data into the Integer definition, if the upper bit happens to be "1", you do not want sign extension. Bob Colestock VDA. -----Original Message----- From: kds@mitretek.org [mailto:kds@mitretek.org] Sent: Thursday, April 26, 2001 2:45 PM To: imc-snacc@imc.org Subject: SNACC integer size too small for PKI ? Hey. Quick question for whoever out there can help... Various PKI structures, such as X509 certificates (field: certificateSerialNumber), contain fields of asn.1 type "INTEGER" In common usage, these serial numbers tend to be very large (16 bytes or so), but SNACC appears to be have its internal type AsnIntType tied to 32 bit intereger. So- I'm having problems getting SNACC to create or parse just about anything PKI related. I get AsnInt::BDecContent: ERROR - integer is too big to decode when I try to decode, and cannot find any method to allow me to load the internal AsnInt state to a large value to try and encode. Is there some other SNACC type I should be using? (LONG INTEGER doesn't appear to parse.) Should I try to trick SNACC by creating my own pre-compiled code type that mimics "OCTET STRING" but changes the TAG to "UNIV,PRIM,INTEGER_TAG_CODE" ? Any ideas would be most appreicated! - Ken Stillson, kds@mitretek.org -- | Ken Stillson | stillson@mitretek.org | | Sr. Principal Engineer | voice: (703) 610-2965 | | Mitretek Systems | fax: (703) 610-2984 | From owner-imc-snacc Fri Apr 27 11:42:46 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA13545 for imc-snacc-bks; Fri, 27 Apr 2001 11:42:46 -0700 (PDT) Rec