Certs and CRLs

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

Recent questions about when and how to transfer certificates and
CRLs in XCBF indicate a need for further discussions, which may
lead to new work in version two.

In classic PKCS #7, the SignedData type evolved from a more
simple format to the one we use in XCBF today. As the need for
certificate distribution became apparent, the certificates and CRLs
"saddlebags" were added to the signed data wrapper.

Eventually, a so called "degenerate" form of SignedData was created.
In this case there are no signers of the content and the content is
omitted from the message. So, there are no values of type SignerInfo
in the SignerInfos set. Typically, the DigestAlgorithms set is empty
and the content type (though there is none) is ordinary data.

This format is used in many existing applications, such as secure email,
IPSec, and X9.24 Retail Financial Services Symmetric Key Management
Part 1: Using Symmetric Techniques. It allows for certificate and CRL
distribution to occur outside of or independent of the messages specified
in an application or protocol. Perhaps we should define such a message in
the next version of XCBF.

I note that the OriginatorInfos was added to a late version of X9.73 CMS,
and did not appear in the original X9.84 work. I agonized over whether to
put this into the recent X9.84 revision, putting it in then taking it 
out, putting
it in then taking it out, and finally decided to add it to the standard. 
I'm still
not convinced that it is needed or will ever really be used. In 
practice, users
are far more likely to transfer certificates in an Integrity object or a 
Privacy
and Integrity object. In both of these, the SignedData component will most
likely carry any needed certificates.

But as a practical matter, the authors of the original X9.84 believed 
that all
needed certificates would actually be distributed out of band and prior to
the use of the X9.84 messages. They believed that CRLs would not be used
at all, and that instead OCSP would be used. The SignedData saddlebags
were kept in largely for the purpose of key updating - certificates 
expire and
need to be replaced. But discussion in the standard of this topic was 
deemed
to be out of scope.

Perhaps we should define or recommend more details of the processing needed
to validate the certificates associated with the encryption and 
signatures in the
XCBF standard. Perhaps we should specify a certificate request message for
use in XCBF, a subset of PKCS #10, and an associated PKCS #7 message
for returning the certificates from a CA. Perhaps we could define an OCSP
extension for use in XCBF certificates, to assist applications with 
validation.

And perhaps we should provide more details of the key management and
certificate requirements for XCBF, as these topics must be addressed by
XCBF applications if they are to be secure. I note that a minor issue not
discussed in either X9.84 or XCBF is that each party should have two
key pairs and two public key certificates. One key pair should be a public
encryption key and a private decryption key. The other should be a private
signature key and a public verification key. This splitting of 
functionality is
commonly referred to as "good key hygiene".

Providing more details in these areas might assist users of the XCBF 
standard
and help to promote interoperable solutions.

Phil