Subject: RE: Required Algorithms for Certificates

From: Al Arsenault <[email-masked]>
Date: Thu, 21 Dec 2000 14:52:23 -0500

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: "Jim Schaad" <[email-masked]>
Date: Thu, 21 Dec 2000 11:55:33 -0800

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,

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

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

			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

Russ

again,
is

---

From: "Al Arsenault" <[email-masked]>
Date: Thu, 21 Dec 2000 15:15:10 -0500

OK, I get it now. The fact that the CA CAN sign with RSA doesn't mean that
it will, and of course the client can't tell the CA in advance "I'm gonna
need a cert with this signature algorithm, so be sure to use it."

That makes sense.  :-)

To be honest - I was thinking in terms of a registration scenario, where the
subject could tell the CA through some means that "I can only verify RSA, so
make sure you use that" and the CA could use whatever alg was requested.
That's what I get for not thinking about the more general case.

I'm still not happy with the client having to support multiple algorithms,
though, so I work with a number of clients that don't support multiple
algorithms and likely never will.  It might be easier then to only mandate
RSA, and let everything else be a SHOULD or MAY.

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 21 Dec 2000 12:41:43 -0800

I agree with Al.  My vote is lock down RSA as a SHALL, DSA as a SHOULD and
others as a MAY.

Mike

-----Original Message-----
From: Al Arsenault [mailto:[email-masked]]
Sent: Thursday, December 21, 2000 12:15 PM
To: [email-masked]; [email-masked]
Subject: Re: Required Algorithms for Certificates

That makes sense.  :-)

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.