OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pki-tc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: PKI in SOAP

Attached is a document that might be of interest to our TC. This
was distributed last week to the US shadow of ISO/IEC JTC1
SC6, iNCITS T3. The document is public describes inputs that
may be used to create a proposal for a new work item in SC6.

The notion is to provide a standard means of compressing SOAP
envelope XML markup, to enable more efficient transfer and storage
in a compact binary format. The sender and recipient of these SOAP
messages would see XML markup, but on the "wire" between them
a compact binary format would be used.
But the encoding rules being suggested in this SC6 proposal would
not positively benefit PKI users. The proposal as currently written
is to use the Packed Encoding Rules (PER) of ASN.1. But X.509
certificates and CRLs are defined in a completely different ASN.1

Certificates and CRLs are defined using the Basic Encoding Rules
(BER) and the Distinguished Encoding Rules (DER) of ASN.1. So,
under this proposal, X.509 certificates and CRLs would not be a
native transfer format for SOAP envelopes. They would be as alien
to SOAP messages as an MPEG file or a Word document. They
would require additional processing, storage and programming code
to be used in this proposed transfer scheme.

In SOAP usage (as in OASIS WSS) BER encoded certificates and
CRLs must be Base64 encoded to make them 'mail safe' text before
they can be embedded in a SOAP envelope for transfer. The recipient
must then convert the Base64-encoded certificates back into their
original binary format to actually use them. This process preserves the
integrity of these signed objects. Their signatures can only be verified
when they are in the original format that was signed.

If BER were used for SOAP transfer and compression instead of PER,
this Base64 encoding step would not need to be performed by the
message sender and the Base64 decoding process would not need to
be performed by the message recipient. But if PER is used for SOAP
transfer as currently suggested, X.509 certificates and CRLs would need
to be treated as objects in an alien format. They would need to be Base64
encoded before transfer, then decoded by the SOAP envelope recipient
before actual use.

Another consideration is current PKI vendor tools. These are all BER and
DER based, and almost certainly do not support PER. The NIST sponsored
SNACC tools support only BER and DER. And there are very few vendors
of PER based tools - many telecoms though have in house PER tools, but
these are generally proprietary and not for sale.

The introduction of an additional encoding format such as PER into SOAP
envelopes increases the overhead needed to support PKI based messaging
when PER is not supported by network devices - as is now the case. This
could negatively impact adoption and use of DER based certificates in SOAP
based applications.

But a BER transfer syntax could be very beneficial to PKI adoption. This
approach would turn X.509 certificates and CRLs (as well as some public
and private keys and signatures that are DER encoded) into "first class"
XML objects, since at transfer time, they would be in a native format.

If BER were used in this SC6 proposal, Base64 processing of X.509
objects could be eliminated. This would reduce processing time as well
as the number of bytes that would need to be transferred. It might be in the
best interest of the PKI TC to try to influence the proposal that finally goes
into ISO and IEC so that it better meets the needs of PKI users.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]