PKI in SOAP

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