PKI in SOAP

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

Title:

                      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 
format. 

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.

Phil

N12469.doc