Subject: RE: Required Algorithms for Certificates

From: Philip Hallam-Baker <[email-masked]>
Date: Thu, 21 Dec 2000 13:12:33 -0800

I think that it is important to first recognize the reality that RSA is the
primary algorithm for PKIX and that clients MUST support it.

I don't think that it is appropriate to actually mandate any algorithm for
servers except in respect of support for interoperability testing since a CA
may have a policy of only issuing certs signed with one specific algorithm.
There is no particular advantage in having multiple algorithms for testing.
Mandating RSA therefore makes sense.

I don't think that servers should be mandated to support anything other than
RSA. Although the "Housely Compromise"[1] would be a way of avoiding
breaking faith with folk who went off and implemented non RSA PKIX.

We could mandate DSA for clients but I have not heard a compelling argument
on either side. The code is not exactly burdensome. I guess having made it a
MUST we can't really go back to SHOULD but we can add in a MUST.

So I guess the "Housely Compromise" makes sense.

	Phill

[1] Sounds like a landmark in diplomatic history n'est pas?

> -----Original Message-----
> From: Al Arsenault [mailto:[email-masked]]
> Sent: Thursday, December 21, 2000 2:52 PM
> To: 'Russ Housley'; [email-masked]
> Subject: RE: Required Algorithms for Certificates
> 
> 
> Russ, et alia,
> 
> 	While I wasn't in San Diego and thus I'm not up to 
> speed on those 
> particular discussions, this proposal seems backward to me.  
> It seems to 
> put the complexity (specifically, support for multiple 
> algorithms) on the 
> client, vice the server.  Generally, I prefer to see the 
> complexity put on 
> the server, and let the clients be simpler.  (This is in line 
> with certain 
> other standards bodies/industry fora, which 
> mandate/recommend/whatever that 
> CAs support all of RSA, DSA, and ECDSA, and let clients 
> support whichever 
> one they want.)
> 
> 	So my recommendation would be that:
> 
> 	CAs MUST be able to sign certificates and CRLs with all 
> of the following:
> 
> 		RSA with SHA-1, and
> 		DSA with SHA-1
> 
> 	Certificate users MUST be able to validate signatures 
> on certificates and 
> CRLs with at least one of the following:
> 
> 		RSA with SHA-1, or
> 		DSA with SHA-1.
> 
> 	(This of course begs a number of questions, like: do 
> CAs have to sign CRLs 
> if they support OCSP instead; do certificate users have to be able to 
> process CRLs if they instead rely on OCSP?, etc.)
> 
> 	In response to Ambarish's posting, and to Bob 
> Jeunemann's and others' 
> earlier postings about whether DSA should really be a MUST 
> since almost 
> nobody uses it, my personal believe is that DSA should be a 
> MUST just in 
> case there are any backward compatibility issues that might 
> come up.  If 
> it's not a MUST, then I strongly prefer SHOULD to MAY. If DSA 
> becomes less 
> than a MUST, then of course the requirements above reduce to "CAs and 
> clients MUST support RSA with SHA-1", with appropriate 
> wording for DSA.
> 
> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 
> 
> 
> -----Original Message-----
> From:	Russ Housley [SMTP:[email-masked]]
> Sent:	Wednesday, December 20, 2000 12:06 PM
> To:	[email-masked]
> Subject:	Re: Required Algorithms for Certificates
> 
> As everyone who was at the meeting in San Diego knows, this 
> posting lead to 
> a long discussions in PKIX, S/MIME, and SAAG sessions.  Based on those
> discussions, I suggest a possible way forward for son-of-rfc2459.
> 
> CAs MUST be able to sign certificates and CRLs with at least 
> one of the
> following:
>          - DSA with SHA-1, or
>          - RSA with SHA-1.
> 
> CAs MAY sign certificates and CRLs with any additional 
> algorithms that they 
> wish.
> 
> Certificate users MUST be able to validate signatures on 
> certificates and
> CRLs with all of the following:
>          - DSA with SHA-1, and
>          - RSA with SHA-1.
> 
> Certificate users MAY validate signatures on certificates and 
> CRLs with any 
> additional algorithms that they wish.
> 
> Russ
> 
> At 05:45 PM 12/12/2000 -0800, Jim Schaad wrote:
> >In reviewing the algorithm draft 
> (draft-ietf-pkix-ipki-pkalgs-01.txt) 
> again,
> >I remembered that I did have one problem with the draft.  I 
> think that it 
> is
> >fine that the certificate structure draft does not contain algorithm
> >information.  However I feel that the algorithms draft needs 
> to have some
> >MUST style statements contained in it.  I propose adding the 
> following 
> text:
> >
> >To fully comply with this document, implementations MUST support DSA
> >Signature (section 2.2.2).  Implementations MAY support MD2 
> RSA signatures
> >for validation but MUST NOT create new certificates using 
> this algorithm.
> >Implementations MAY support all other algorithms in this 
> document at their
> >discretion.
> >
> >jim schaad
>

---

From: "Singer, Ari" <[email-masked]>
Date: Thu, 21 Dec 2000 16:54:54 -0500

Hi, everyone.

This is my first posting to this list, so please indulge me if I am not 100%
familiar with all of the context here.  My apologies also for the length of
this posting.  I guess I should comment more often to keep the size down. :)

I would like to get a little clarification about what exactly our goal is in
specifying MUSTs, SHOULDs and MAYs for these algorithms.  It seems to me
that there are two primary goals, which are interoperability and ease of
deployment for the maximum number of implementations.  Which of these two
goals takes precedence when there is a choice, I would love to know
(although I am certain there won't be concensus on that issue).  There also
seem to be lots of other variables that creep into the discussions like
timing of when things will be deployed.

The interoperability question is the most confusing part for me.  In both
Al's example and Russ's example, the CA and the client MUST be able to
interoperate with each other.  The difference is that in Russ's case, a
certificate owner can always get a single certificate from any CA that all
complying client's can verify (that isn't to say that the client necessarily
trusts the CA).  In Al's case, the certificate owner can get two
certificates from any CA (one with RSA and one with DSA) and then if the
certificate owner knows which one the client needs, they are also okay.   

One point I want to make is that in both cases, two entities will not
interoperate if one party has a certificate that is signed with an alternate
algorithm (like ECC) and the other doesn't verify that, yet this is allowed.
What this says to me is that we are always allowing non-interoperability
between implementations that comply with the standard.  If that is the case,
what is the actual meaning of having a MUST implement?  

As far as my personal opinion goes, I agree with Al that it makes sense to
try to minimize the number of MUSTs on the client side because clients are
far more likely than CAs to have processing/memory constraints.  Forcing
multiple algorithms on a client could prove to be burdensome, whereas
forcing the CAs to implement more than one algorithm probably isn't as
painful (although I'm sure someone might argue that there are infrastructure
costs for CAs).   

That being said, I have thought a bit about what should be mandatory and
what shouldn't and why.  Here are my recommendations and reasons for the
choices.  I would welcome any comments on this.

CAs MUST be able to sign certificates and CRLs with the following:
         - RSA with SHA-1. (Because at the San Diego meeting, the general
consensus was that for future applications, RSA (at least) should be a MUST
implement)

CAs MAY be able to sign certificates and CRLs with the following:
         - DSA with SHA-1. (Because it is certainly an acceptable algorithm
and there may be existing applications that need DSA.  It seems, though,
that future signatures probably won't have to be DSA as much, since most
everyone will be able to verify RSA signatures.)

CAs MAY also sign certificates and CRLs with any additional algorithms that
they wish. (Because there may be good reasons to use other algorithms for
particular applications.)

Certificate users MUST be able to validate signatures on certificates and
CRLs with the following:
         - RSA with SHA-1. (Because we need to have interoperability and
everybody (except constrained devices) likes RSA now that it is no longer
covered by patents.)

Certificate users SHOULD be able to validate signatures on certificates and
CRLs with the following:
         - DSA with SHA-1. (Because we don't want to force clients to
support multiple algorithms, but they are likely to encounter DSA
certificates.)

Certificate users MAY be able to validate signatures on certificates and
CRLs with any algorithm that they wish. (Clearly, clients should be allowed
to verify any certificates CAs are allowed to sign.)

Clearly the above solution allows people to not be interoperable, but I
haven't seen any proposal (and I don't think there should be one) that
outlaws non-interoperability.

Well, I think that's all for now.  If you made it this far down the e-mail,
thanks for reading! :)

Best regards,
Ari

Ari Singer, Principal Engineer
NTRU
5 Burlington Woods
Burlington, MA 01803
Main: (781) 221-0017
Personal: (781) 221-1306
Fax: (781) 221-0117

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 2:56 PM
To: 'Al Arsenault'; [email-masked]
Subject: RE: Required Algorithms for Certificates

OK Al,

If we go with your proposal, your client validates RSA with SHA-1 and my CA
generates DSA with SHA-1.  We are in the situtation of no interop.

If we uses the rules stated in the posting by Russ, we always have interop.

jim

-----Original Message-----
From: Al Arsenault [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 11:52 AM
To: 'Russ Housley'; [email-masked]
Subject: RE: Required Algorithms for Certificates

Russ, et alia,

	While I wasn't in San Diego and thus I'm not up to speed on those
particular discussions, this proposal seems backward to me.  It seems to
put the complexity (specifically, support for multiple algorithms) on the
client, vice the server.  Generally, I prefer to see the complexity put on
the server, and let the clients be simpler.  (This is in line with certain
other standards bodies/industry fora, which mandate/recommend/whatever that
CAs support all of RSA, DSA, and ECDSA, and let clients support whichever
one they want.)

	CAs MUST be able to sign certificates and CRLs with all of the
following:

		RSA with SHA-1, and
		DSA with SHA-1

		RSA with SHA-1, or
		DSA with SHA-1.

	(This of course begs a number of questions, like: do CAs have to
sign CRLs
if they support OCSP instead; do certificate users have to be able to
process CRLs if they instead rely on OCSP?, etc.)

	In response to Ambarish's posting, and to Bob Jeunemann's and
others'
earlier postings about whether DSA should really be a MUST since almost
nobody uses it, my personal believe is that DSA should be a MUST just in
case there are any backward compatibility issues that might come up.  If
it's not a MUST, then I strongly prefer SHOULD to MAY. If DSA becomes less
than a MUST, then of course the requirements above reduce to "CAs and
clients MUST support RSA with SHA-1", with appropriate wording for DSA.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

-----Original Message-----
From:	Russ Housley [SMTP:[email-masked]]
Sent:	Wednesday, December 20, 2000 12:06 PM
To:	[email-masked]
Subject:	Re: Required Algorithms for Certificates

As everyone who was at the meeting in San Diego knows, this posting lead to
a long discussions in PKIX, S/MIME, and SAAG sessions.  Based on those
discussions, I suggest a possible way forward for son-of-rfc2459.

CAs MUST be able to sign certificates and CRLs with at least one of the
following:
         - DSA with SHA-1, or
         - RSA with SHA-1.

CAs MAY sign certificates and CRLs with any additional algorithms that they
wish.

Certificate users MUST be able to validate signatures on certificates and
CRLs with all of the following:
         - DSA with SHA-1, and
         - RSA with SHA-1.

Certificate users MAY validate signatures on certificates and CRLs with any
additional algorithms that they wish.

Russ

At 05:45 PM 12/12/2000 -0800, Jim Schaad wrote:
>In reviewing the algorithm draft (draft-ietf-pkix-ipki-pkalgs-01.txt)
again,
>I remembered that I did have one problem with the draft.  I think that it
is
>information.  However I feel that the algorithms draft needs to have some
>MUST style statements contained in it.  I propose adding the following
text:
>Signature (section 2.2.2).  Implementations MAY support MD2 RSA signatures
>for validation but MUST NOT create new certificates using this algorithm.
>Implementations MAY support all other algorithms in this document at their
>discretion.
>
>jim schaad

---

From: Al Arsenault <[email-masked]>
Date: Thu, 21 Dec 2000 18:45:46 -0500

Tim,

	Comments in-line, prefaced by my initials "AWA".

-----Original Message-----
From:	Tim Polk [SMTP:[email-masked]]
Sent:	Thursday, December 21, 2000 5:05 PM
To:	[email-masked]
Subject:	RE: Required Algorithms for Certificates

Folks,

Since different algorithms are a natural fit for different applications,
the selection of a single MUST algorithm for PKIX seems a bad idea.  That
is the reason Jeff Schiller let us avoid this issue in the first place.  If 
S/MIME chooses RSA but IPsec chooses DSA and D-H, we would be in conflict
with at least one of them.  PKIX should not be in the position of dictating 
algorithms to other working groups.  If PKIX decides to specify MUSTs or
SHOULDs, they should be designed to support broad interoperability.

AWA: Agreed.

Interoperability is a prime concern here at NIST.  In terms of algorithm
independence, we have come to the conclusion that interoperability
*requires* multi-algorithm clients.  Yes, it would be nice to move the
burden to CAs since there will be relatively few CAs.  However, CAs that
can sign with multiple algorithms doesn't help clients that verify with
only one unless they issue each certificate multiple times, using each
supported signing algorithm.  Not a solution, IMHO!

AWA: Agreed, in general.  Although we've found that for some specialized 
cases, it winds up being easier to just issue two certs, one with each of 
two signing algorithms.  That way it means we can support a wider set of 
clients, without having to modify them. I certainly don't want to force 
that solution on the populace at large; I'm just saying that it sometimes 
works out to be an acceptable solution.

This implies that we need to move the burden to the clients, even though
that will impact many clients.  If a PKIX client can validate both DSA and
RSA signatures, it can handle certificates from any CA when signed with a
PKIX-specified algorithm.  The client will never be forced to reject the
certificate based on the signing algorithm - to me, that's
interoperability.  (I am assuming, of course, that the client knows how to
use the end entity's public key.  If the certificate contains a D-H key,
and the client can't do D-H we still break down.  It wasn't the signature
algorithm on the certificates that broke it, though...)

AWA: Here I disagree.  As Ari has already pointed out, PKIX - and Russ' 
suggestion - allows the CA to use whatever algorithm it wants.  Thus, a CA 
can use ECDSA (to pick on one algorithm) and it's still completely 
PKIX-compliant, as long as it could have also done RSA but chose not to. 
Any client that doesn't support ECDSA will choke on this certificate, and 
reject it with some error message or another. Thus, we have "PKIX 
compliance" at both the client and CA, but no interoperability.

The question is whether multiple algorithm support is a practical
requirement for clients.  I just took a few minutes to scan the FIPS 140-1
validated crypto module list.  This list currently has 130 modules - some
hardware, some software.  (For those interested, see
http://csrc.nist.gov/cryptval/140-1/1401val.htm)  Many of those
cryptographic modules already support multiple signature algorithms.   I
didn't count, but it appears that most of the recent products (both
hardware and software) support both DSA and RSA for signatures.

To me, this implies that multiple algorithm support is reasonable unless
the device footprint must be very small.  This may be a biased data set,
though.  Validated products are required to support at least one
FIPS-approved algorithm, and RSA has only recently become a FIPS-approved
algorithm.

AWA: for typical "Internet clients", you're almost assuredly right. 
 However, I tend to work with a set of client devices that are more 
constrained than most Internet developers typically see, so I'm 
particularly sensitive to this.  (If anyone has ever tried to implement a 
PKI client on a device with less than a 23 byte stack and 147 bytes of RAM, 
let me know.  :-)

Anyway, I personally like Russ's proposal.  I believe it doesn't put too
great a burden on PKI clients and would foster interoperability.

AWA:  I'm more inclined to say that DSA should be a "SHOULD" at this point. 
Yes, as Phill pointed out, it seems to be breaking faith with those who 
implemented non-RSA PKIX, and so I wouldn't be terribly saddened to see DSA 
be a "MUST", but I'd rather it be a SHOULD for the client at this point.

My $0.02 (which may in fact be overpriced.)

Thanks,

Tim Polk

		Al Arsenault

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 22 Dec 2000 08:11:31 -0800

Many PKis (little i) does not necessarily equal a PKI (big I). A PKI (big I)
does, however, enable PKis (little i). So I am still not convinced that our
current path will result in a PKI (big I). Please excuse the wordiness.

Frank

> From: Yuriy Dzambasow [mailto:[email-masked]]
> Sent: Friday, December 22, 2000 11:03 AM
> To: Frank Balluffi; 'Marc Branchaud'; [email-masked]
> The reality is, in my opinion, that there will be PKIs (BIG 
> I's) and PKis
> (Little i's), both of which wanting to claim PKIX compliance. 
>  To achieve
> that, I think there are two options, both of which I can support:
> 
> 1) Mandate a single algorithm on clients and CAs (RSA with 
> SHA-1), and state
> the others are MAY implements
> 2) Do not specify anything in son-of-2459 with respect to required
> algorithms, but rather provide text that encourages CAs to 
> implement support
> for algorithms based on applications that the CA needs to support, and
> further, have groups like S/MIME, TLS, and IPSEC define the required
> algorithms.
> 
> Yuriy
> 
> From: Frank Balluffi [mailto:[email-masked]]
> Sent: Friday, December 22, 2000 10:22 AM
> To: 'Marc Branchaud'; [email-masked]
> Marc Branchaud said:
> > I suggest that the expectation of a single "omnicert" is
> > turning out to be
> > naive.
> 
> It seems to me that the REAL issue is whether we want a PKI 
> which anyone can
> dynamically plug into or a PKi (note the small i) which only 
> pre-arranged
> groups can plug into. I would prefer the former. My sense is 
> that MUST RSA
> has a better chance of satisfying the former for the 
> following reasons:
> 
> 1. one algorithm minimizes the number of algorithm combinations
> 2. RSA can be used for both signing and encryption
> 3. RSA already has more critical mass than DSA
> 4. one algorithm minimizes the system resource usage on small 
> footprint
> devices
> 5. RSA is in the public domain
> 
> Also, I do not see a problem with changing MUST DSA to {SHALL 
> | MAY} DSA as
> long as a it is scheduled with reasonable warning. There was 
> a good reason
> for mandating DSA and that reason has changed.
> 
> To reiterate, the question remains, "What the heck are we trying to
> accomplish here?"
> 
> Frank
> 
> > From: Marc Branchaud [mailto:[email-masked]]
> > Sent: Thursday, December 21, 2000 7:28 PM
> > To: [email-masked]
> > Tim Polk wrote:
> > > algorithms to other working groups.
> >
> > There's the rub.  PKIX can't choose a (set of) algorithm(s)
> > because PKIX is
> > so broadly applicable that any choice would shut out a
> > particular community.
> > It looks like algorithm choice is really up to the application.
> >
> > That would be fine, but there seems to be an expectation that
> > there is only
> > one certificate for a given entity, and that an entity is
> > expected to use its
> > one certificate for all its applications.
> >
> > Those two positions are irreconcilable.  Either a user has
> > one cert for
> > S/MIME, SSL, IPSec, etc. (in which case all those
> > applications will have to
> > use the same algorithm) or the user has multiple certs.  You
> > can't have it
> > both ways.
> >
> > I suggest that the expectation of a single "omnicert" is
> > turning out to be
> > naive.  Already with existing deployments, users have
> > different certs for
> > their different applications.  Even users of integrated
> > applications (say, a
> > browser & S/MIME app) tend to have distinct certs for each protocol.
> >
> > > If PKIX decides to specify MUSTs or SHOULDs, they should be
> > designed to
> > > support broad interoperability.
> >
> > Yes, but what kind of interoperability?  Does an S/MIME cert
> > have to be
> > interoperable with an SSL cert?  Put another way, will an
> > S/MIME application
> > ever need to use or process an SSL or IPSec cert?  I say no.
> > If you accept
> > that, then interoperability across all protocols becomes 
> meaningless.
> >
> > So it makes sense for the algorithm decision to be in the 
> hands of the
> > protocols that adopt PKIX.  In fact, the "users" of PKIX are
> > really other
> > IETF protocols.  Therefore, I suggest that PKIX have only one
> > MUST with
> > respect to algorithms:
> >
> >    Protocols that adopt PKIX SHALL require their applications
> > to implement
> >    one of the PKIX-compliant algorithms described in [RFCx],
> > [RFCy] and
> > [RFCz].
> >    PKIX implementors SHOULD implement the algorithm(s) 
> required by the
> >    protocol(s) which their PKIX implementation will support.
> >
> > This is a kind of meta-requirement for using PKIX, and I
> > don't know if IETF
> > rules allow for that sort of thing.  But I do think it's a
> > reasonable way
> > forward, because other protocols are then free to make the
> > best choices for
> > themselves.  S/MIME, for example, could say 
> "implementations SHALL use
> > [PKIX1] certificates that contain an RSA public key and that
> > are signed using
> > RSASHA1."  IPSec could make similar requirements for, say,
> > DSA & DH.  As long
> > as nobody tries to use their S/MIME cert for their VPN,
> > things will work.
> >
> > One final note: People who want to build generic PKIX
> > toolkits are likely
> > going to need to implement all the PKIX-compliant algorithms.
> >  This is pretty
> > much a given anyway (look at the existing toolkits).  What's
> > really at issue
> > are application developers who aren't using a general PKIX toolkit.
> >
> >               Marc
> >
> > +-------------------------------------------------------------
> > -----------+
> >  Marc Branchaud                                  \/
> >  Chief PKI Architect                             /\CERT
> > INTERNATIONAL INC.
> >  [email-masked]        PKI References page:
> www.xcert.com
>  604-640-6227          www.xcert.com/~marcnarc/PKI/
> +-------------------------------------------------------------
> -----------+
>

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 29 Dec 2000 11:18:10 -0700

I agree with Paul. I see absolutely no move to support DSA/DH in S/MIME, 
SSL/TLS, or IPSEC, regardless of what the IETF standards state.

We implemented DSA within NICI primarily because it was available in BSAFE, 
relatively easy to do, and was required for any meaningful compliance with 
FIPS 140-1 at the time, NOT because we expected anyone to ever use it.

Within a more or less general-purpose crypto library, the overhead isn't all that
great, and clearly there isn't any issue of interoperability at the API level to 
worry about, so in that environment I more or less don't care.  However, if
I were trying to develop some crypto applications on a tiny-weenie processor
like a credit card, that would be a much different story. Then I would simply
be non-compliant, rather than include something that provided me no benefit.

Other than avoiding the intellectual property issues (which are now moot), I see 
no reason to make DSA even a SHOULD, much less a MUST.  I wouldn't argue
with a MAY, if that helps people (both of them? :-) who have already implemented 
DSA because they actually believed the standards, or because they thought that 
if the Government required it as part of their procurement specs, they would actually 
buy (only) those products that complied. But I don't think there is any issue that DSA 
is a dead horse.

The real issue, I believe, is going to be between RSA and ECDSA.  RSA obviously 
has a lot going for it as the de facto standard.  And ECDSA also has a lot going for it,
in terms of compactness and minimum power requirements.

I don't have a good crystal ball that would tell me whether WAP and some of the 
other wireless applications are going to succeed or fail. Personally, I have a 
mini-browser built into my cellular phone (a Samsung), and I have yet to find ANY
application for it that is worth the hassle, much less the airtime.  Maybe if I were 
a day trader I would view things differently.

But although I'm still looking for that killer application, I would not be inclined
to bet against the possibility.  Somebody, somewhere, will probably come up with
something useful.

And in that case, I think that ECDSA will become a requirement.

Because of all of the existing CAs and certificates, those applications are going 
to have to continue to support RSA-signed certificates for the indefinite future.
Fortunately, validating an RSA signature is a lot easier than generating one.

But because digitally signing something is a lot easier (in terms of power and 
size) with ECDSA, end-user certs for such applications are going to have to 
contain ECDSA signing keys, even if the certificates themselves are signed 
with RSA for the time being.  And there will be pressure to have the certs 
themselves signed with ECDSA, in order to reduce the overall size.

So maybe the requirement hasn't quite materialized, but I would support making
RSA a MUST, deprecating DSA to a MAY, and making ECDSA a SHOULD, 
with the option of transitioning ECDSA to a MUST if and when a critical mass 
of implementations and users can be demonstrated.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc -- the leading provider of Net services software

>>> Paul Hoffman / VPNC <[email-masked]> 12/21/00 04:53PM >>>
At 5:04 PM -0500 12/21/00, Tim Polk wrote:
>If PKIX decides to specify MUSTs or SHOULDs, they should be designed 
>to support broad interoperability.

Exactly. It is easier to get interoperability with one algorithm than 
with two, particularly when one of those algorithms hasn't been 
widely implemented and tested in products.

>Interoperability is a prime concern here at NIST.  In terms of 
>algorithm independence, we have come to the conclusion that 
>interoperability *requires* multi-algorithm clients.

Could you explain the logic there a bit more? If only one algorithm 
is mandated, how does that leasd to less interoperability?

>This implies that we need to move the burden to the clients, even 
>though that will impact many clients.

Here we disagree. Do you *really* think that all the IPsec 
implementations and all the S/MIME implementations are going to add 
DSA support? That is certainly not what I hear from the members of my 
organizations; even the ones who do DSA support are not sure that it 
works that well because it is rarely tested.

>   If a PKIX client can validate both DSA and RSA signatures, it can 
>handle certificates from any CA when signed with a PKIX-specified 
>algorithm.

If we only mandate RSA, well, you can fill in the rest...

>requirement for clients.  I just took a few minutes to scan the FIPS 
>140-1 validated crypto module list.  This list currently has 130 
>modules - some hardware, some software.  (For those interested, see 
>cryptographic modules already support multiple signature algorithms. 
>I didn't count, but it appears that most of the recent products 
>(both hardware and software) support both DSA and RSA for signatures.
>
>To me, this implies that multiple algorithm support is reasonable 
>unless the device footprint must be very small.  This may be a 
>biased data set, though.  Validated products are required to support 
>at least one FIPS-approved algorithm, and RSA has only recently 
>become a FIPS-approved algorithm.

Bingo: that obviously skewed the requirements. In the IPsec and 
S/MIME space, there was no such requirement (that is, S/MIME vendors 
simply ignore the v3 specs), and there are almost no commercial or 
even freeware implementations using DSA.

--Paul Hoffman, Director
--VPN Consortium