>From: Mr Rhys Weatherley <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>
>Subject: Re: encoding of Certificate abstract syntax
>Date: Thu, 15 Sep 1994 10:13:14 +1000 (EST)
>On Wed, 14 Sep 1994, Peter Williams wrote:
>
>> The encoding rules for encoding or "presenting" ASN.1 Certificate
>> values when conforming to the ISO 9735 EDIFACT standard - the
>> international EDI application of messaging - are given in the
>> "UN/EDIFACT Security implementation Guidelines." Given the nature of
>> the EDIFACT syntax level definitions used to constrain multilateral and
>> [...]
>
>I know zip about EDIFACT, but your following comments about encoding '@'
>and whatnot seem a bit weird to me. A BER-encoded Certificate is already
>a very weird binary object that will need something like base64 (which
>supposedly would get through Telex machines fine). Whether '@' is used or
>not is irrelevant once the base64 wrapper has been added. I've probably
>missed something though, so forgive this tired Aussie if that is the case.
You missed the fact that EDIFACT, in best ISO and OSI
commercially-driven tradition, specifies its own encoding rules for the
Certificate Value. These do not resemble BER, or derivatives, though
are canonical. This value, suitable for transmission over telex and
X.400/telex without further recoding to suit network path capability
restrictions, is SIGNED. The bitstring which results is "filtered"
(wonderful misused EDIFACT term) from 8bit octets to a printable form,
assuming the worst about capabilities of the transport channels; much
like MIME-PEM and PEM design had to deal with the problems of Internet 7-bit
822/MTP infrastructure constraints.
>> "To: /S=williams/OU=Sterling/O=ARC/PRMD=NASA/ at arc.nasa.gov"
>
>The X.400 forms are unnecessarily verbose and include unnecessary routing
>instructions (ADMD=TELEMAIL). IMHO of course.
How about
"/CN=<DUNS+4>/O=DUNS/ADMD=Sterling/ at arc.nasa.gov" for the EDI traffic.
(We should leave Certificate DNs as they are for personal privacy, and command
and control accountability, purposes, in my opinion.)
(Sterling is not an X.400 provider - but a VAN. I dont believe the
company could give a damn about which technology camp or
company/Internet-provider is used to relay between its messaging
handling access points, so along as it has the opportunity to have its
customers address its (versus competitors available at the same
arc.nasa.gov) Value added EDI or military security services when
they choose, competitively, to use Internet message relays and
messaging tunnels, instead of RJE or X.400.
The verbosity claim is thus a little unfair; the Internet has to
consider commercial reality in its technical evolution, as it turns
into a service provider to businesses. How users and resellers organize their
internal
MTA/MHS routing domain is really not up to the other business party; perhaps I
have security concerns about Internet-based hackers!?
Thus It may be that the Sterling Software operated NASA MTA is a secure
MTA, whose communication and connectivity characteristics are
maintained secret from domains outside of ARC to prevent certain types
of messaging (and network, and system) attacks, and offer services, not
contemplated by the PEM design. Yet its still reasonable to expect
users served by that MTA to be able to interchange PEM, MSP wrapped
IPM, P.772, and EDI with the world, without revealing those
characteristics thereby.