Re: Required Algorithms for Certificates

["Al Arsenault" <aarsenault@xxxxxxxxx>]

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.


----- Original Message -----
From: Jim Schaad <jimsch5@home.com>
To: 'Al Arsenault' <aarsenault@dvnet.com>; <ietf-pkix@imc.org>
Sent: Thursday, December 21, 2000 2:55 PM
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:aarsenault@dvnet.com]
> Sent: Thursday, December 21, 2000 11:52 AM
> 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
>