RE: Required Algorithms for Certificates

[Al Arsenault <aarsenault@xxxxxxxxx>]

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:housley@spyrus.com]
Sent:	Wednesday, December 20, 2000 12:06 PM
To:	ietf-pkix@imc.org
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