Parse error

[subcon42]

Hi

Using two well-known ITU-T ASN.1 modules:

• PKIX1Explicit93
• PKIX1Implicit93
• Note these two modules import FROM each other!

... I am unable to load said modules using the cmd/smi/main.go example file.

This has been tried by combining the above two files into one (and swapping the order), as well as keeping them separate. In the case of separation, we receive lots of "cannot import" messages but I believe that behavior may be expected due to the nature of how these two modules relate to one another.

The error:

Parse file: /var/lib/snmp/mibs/ietf/PKIX-93:36:6: no match found for .

I know it is reading the file, as I can see the offending line (on my concatenated copy, its line 36):

(WITH COMPONENTS {
   ...,                <-- THE FIRST PERIOD IS WHAT IT IS COMPLAINING ABOUT
   authorityCertIssuer        PRESENT,
   authorityCertSerialNumber  PRESENT
 } |
 WITH COMPONENTS {
   ...,
   authorityCertIssuer        ABSENT,
   authorityCertSerialNumber  ABSENT
 })

I realize these aren't "MIBs" per se, but they still contain valid ASN.1 that, by all rites, should be OK to parse.

I can even take these modules, concatenate them together and parse them via OSS Nokalva's ASN.1 Playground (see here). This includes STRICT checking enabled.

I have no issues parsing my /var/lib/snmp/mibs/ietf, /var/lib/snmp/mibs/iana folder contents, aside from a few known (and accurate) reports of invalid SNMP MIBs present on certain GNU OS releases throughout the years (e.g: SNMPv2-TC). Such cases I could confidently disregard as a result.

I am thus wondering if:

• If this is considered a bug in gosmi terms -or- if you believe this violates the precepts and goals upon which gosmi was designed, and ...
• If this can be worked around

Thank you

subcon42

PS --
For reference, here is "healthy" output from the aforementioned OSS Nokalva ASN.1 Playground "concatenated parse job":

OSS ASN-1Step Version 9.0.2
Copyright (C) 2019 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages issued.

ASN1STEP: List of valid unreferenced and/or user-defined PDU numbers and associated PDU names:

       1  AuthorityKeyIdentifier
       2  KeyIdentifier
       3  SubjectKeyIdentifier
       4  KeyUsage
       5  KeyPurposeId
       6  PrivateKeyUsagePeriod
       7  CertificatePoliciesSyntax
       8  PolicyInformation
       9  CertPolicyId
      10  PolicyQualifierInfo
      11  PolicyMappingsSyntax
      12  GeneralNames
      13  GeneralName
      14  EDIPartyName
      15  AttributesSyntax
      16  BasicConstraintsSyntax
      17  NameConstraintsSyntax
      18  GeneralSubtrees
      19  GeneralSubtree
      20  BaseDistance
      21  PolicyConstraintsSyntax
      22  SkipCerts
      23  CRLNumber
      24  CRLReason
      25  HoldInstruction
      26  CRLDistPointsSyntax
      27  DistributionPoint
      28  DistributionPointName
      29  ReasonFlags
      30  IssuingDistPointSyntax
      31  BaseCRLNumber
      32  AuthorityInfoAccessSyntax
      33  AccessDescription
      34  CPSuri
      35  UserNotice
      36  NoticeReference
      37  DisplayText
      38  Certificate
      39  UniqueIdentifier
      40  Version
      41  CertificateSerialNumber
      42  Validity
      43  Time
      44  SubjectPublicKeyInfo
      45  Extensions
      46  Extension
      47  CertificateList
      48  CRLExtensions
      49  CRLExtension
      50  EntryExtensions
      51  EntryExtension
      52  AlgorithmIdentifier
      53  Dss-Sig-Value
      54  DomainParameters
      55  ValidationParms
      56  Dss-Parms
      57  Attribute
      58  AttributeTypeAndValue
      59  Name
      60  RDNSequence
      61  RelativeDistinguishedName
      62  ID
      63  PHGString
      64  ORAddress
      65  BuiltInStandardAttributes
      66  CountryName
      67  AdministrationDomainName
      68  NetworkAddress
      69  X121Address
      70  TerminalIdentifier
      71  PrivateDomainName
      72  OrganizationName
      73  NumericUserIdentifier
      74  PersonalName
      75  OrganizationalUnitNames
      76  OrganizationalUnitName
      77  BuiltInDomainDefinedAttributes
      78  BuiltInDomainDefinedAttribute
      79  ExtensionAttributes
      80  ExtensionAttribute
      81  CommonName
      82  TeletexCommonName
      83  TeletexOrganizationName
      84  TeletexPersonalName
      85  TeletexOrganizationalUnitNames
      86  TeletexOrganizationalUnitName
      87  PDSName
      88  PhysicalDeliveryCountryName
      89  PostalCode
      90  PhysicalDeliveryOfficeName
      91  PhysicalDeliveryOfficeNumber
      92  ExtensionORAddressComponents
      93  PhysicalDeliveryPersonalName
      94  PhysicalDeliveryOrganizationName
      95  ExtensionPhysicalDeliveryAddressComponents
      96  UnformattedPostalAddress
      97  StreetAddress
      98  PostOfficeBoxAddress
      99  PosteRestanteAddress
     100  UniquePostalName
     101  LocalPostalAttributes
     102  PDSParameter
     103  ExtendedNetworkAddress
     104  PresentationAddress
     105  TerminalType
     106  TeletexDomainDefinedAttributes
     107  TeletexDomainDefinedAttribute
     108  CommonName-WITH-SYNTAX
     109  CountryName-WITH-SYNTAX
     110  DnQualifier-WITH-SYNTAX
     111  GenerationQualifier-WITH-SYNTAX
     112  GivenName-WITH-SYNTAX
     113  Initials-WITH-SYNTAX
     114  LocalityName-WITH-SYNTAX
     115  Name-WITH-SYNTAX
     116  OrganizationName-WITH-SYNTAX
     117  OrganizationalUnitName-WITH-SYNTAX
     118  StateOrProvinceName-WITH-SYNTAX
     119  Surname-WITH-SYNTAX
     120  Title-WITH-SYNTAX
     121  ExtendedKeyUsage-SYNTAX
     122  InvalidityDate-SYNTAX
     123  RsaPublicKey-PARMS
     124  RsaSHA-1-PARMS
     125  RsaMD5-PARMS

[sleepinggenius2]

I'm sorry if there has been some misunderstanding, but this library was never meant to support the full extent of ASN.1 notation, only the subset explicitly used for SMI v1 and v2. I might look into a more extensive parser in the future, but that would likely be within a separate library.

[subcon42]

@sleepinggenius2 thank you, I'm glad I asked.

For context, I am writing a draft for a network protocol that would interface with such resources (SMI or ideally ASN.1 in general), and am trying to find a suitable "base" upon which to start.

Thanks for your time!

[sleepinggenius2]

I'm not entirely sure what you are trying to accomplish, but there are certainly a number of protocols out there that currently use ASN.1 for their encoding. SNMP and LDAP are two that I can think of off the top of my head. They generally use a binary encoding though, like BER or DER, for efficiency on the wire. I'm guessing you're looking to utilize the textual notation to define the schema, kind of like you would do with protocol buffers?

[subcon42]

No, not encoding ... but access.

Basically, I was working on implementing something like this in Go.

This is what SMI documentation refers to as the SMI Protocol Server, which as you can see was never really done (but allegedly was planned a long time ago)...

The core drive here (for me) is to make something available that allows for not only storage of SMI/MID/OID information, but also the querying/searching of this data.

Yes I am well aware there are OID websites that allow this kind of activity, but afaik those are all proprietary. My intent was to attempt to give people another option they could use themselves (not to mention a facility for use internally, say within an organization).

[subcon42]

Thanks, take care now.