RE: Required Algorithms for Certificates

[Philip Hallam-Baker <pbaker@xxxxxxxxxxxx>]

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:aarsenault@dvnet.com]
> Sent: Thursday, December 21, 2000 2:52 PM
> To: 'Russ Housley'; ietf-pkix@imc.org
> 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: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
>