Subject: Algorithms in PKIX and S/MIME - query

From: "Richard Lampard" <[email-masked]>
Date: Wed, 30 May 2001 10:38:41 +0100

We recently completed an interoperability trial looking at PKI and S/MIME v3 interoperability. If you're interested, the final report is available at:

www.cesg.gov.uk/cloudcover/PKIdemonstrator.htm 

We are about to embark on a second phase, this time looking at S/MIME v3 encryption. We are keen to mirror current thinking on S/MIME algorithms, which I
believe is:

Signature generation: DSA or RSA may be implemented
Signature processing: DSA and RSA must both be supported
Key transport: RSA

However, I also believe that PKIX thinking at the moment is that DSA is still the mandatory to implement algorithm for certificate and CRL signing.

This leads to the awkward situation where an implementation, for example, only signs S/MIME messages using RSA, but has to sign its RSA transport keys using
DSA. I can imagine other mismatches whereby the keys for one algorithm are signed by a different algorithm.

This seems to stem from the fact that thinking on algorithms between PKIX and  S/MIME is not yet aligned. I'd be very grateful for some advice on how we should
play our second phase, and what we should be asking vendors to bring to the trial. Is it realistic to expect vendors to support both DSA and RSA, especially in
their CAs?

Many thanks

Richard

Richard Lampard
CESG
PO Box 144
Cheltenham
Gloucestershire GL52 5UE
Tel: +441242 221491 x4086
Fax: +441242 709113
**********************************************************************
This email and any files transmitted with it is intended solely for 
the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify 
[email-masked].
**********************************************************************

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 31 May 2001 10:15:13 -0400

Richard:

PKIX has not selected any algorithms as mandatory to implement.  PKIX has 
left such decisions to the protocols that make use of certificates.

S/MIME documents are being updated to reflect:
         signature generation:   RSA or DSA or both
         signature validation:   RSA and DSA
         hash:                   SHA-1
         encrypt:                Triple-DES CBC
         key management: RSA (PKCS#1 v1.5)

Russ

At 10:38 AM 5/30/2001 +0100, Richard Lampard wrote:
>We recently completed an interoperability trial looking at PKI and S/MIME 
>v3 interoperability. If you're interested, the final report is available at:
>
>We are about to embark on a second phase, this time looking at S/MIME v3 
>encryption. We are keen to mirror current thinking on S/MIME algorithms, 
>which I
>believe is:
>
>However, I also believe that PKIX thinking at the moment is that DSA is 
>still the mandatory to implement algorithm for certificate and CRL signing.
>
>This leads to the awkward situation where an implementation, for example, 
>only signs S/MIME messages using RSA, but has to sign its RSA transport 
>keys using
>This seems to stem from the fact that thinking on algorithms between PKIX 
>and  S/MIME is not yet aligned. I'd be very grateful for some advice on 
>how we should
>play our second phase, and what we should be asking vendors to bring to 
>the trial. Is it realistic to expect vendors to support both DSA and RSA, 
>especially in
>their CAs?
>
>Many thanks
>
>Richard
>
>Richard Lampard
>CESG
>PO Box 144
>Cheltenham
>Gloucestershire GL52 5UE

---

From: Tim Polk <[email-masked]>
Date: Thu, 31 May 2001 18:29:47 -0400

Folks,

Russ Housley, David Cooper, and I have tried to draft what we hope *will 
become* consensus text for the delta CRL and CRL number text.  We believe 
that the attached text clarifies (1) the requirements for "conforming 
applications that support CRLs", (2) the CRL issuer's responsibilities when 
including the delta CRL indicator and CRL number extensions, (3) the 
algorithm followed by a CRL issuer when determining what certificates 
should be listed on a delta CRL, and (4) the algorithm followed by an 
application when determining whether a complete CRL and a delta CRL may be 
combined.

To do this we have introduced a number of changes, beginning in section 
3.  In section 3, we introduce the "CRL issuer" in an enhanced version of 
the ASCII art model of a pKI (figure 1.)  In section 5, we define several 
more terms including CRL scope, base CRL, delta CRL and complete CRL.  All 
this was necessary to set the stage for the CRL number extension and delta 
CRL indicator extension text.

Please read these excerpts carefully.  We believe that the text is flexible 
enough to support reasonable implementations of delta CRLs, does not unduly 
burden clients that wish to support deltas, and is consistent with 
X.509.  When you read this please ask yourself if you can *live* with it.

The attachment contains the following excerpts:  Figure 1 from section 3, 
section 5 (the intro to CRLs), section 5.2.3 (CRL number extension) and 
5.2.4 (delta CRL indicator extension).  Please ignore the blank spaces; I 
was trying to remove anything irrelevant to this discussion.

Thanks,

Tim Polk