[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Required Algorithms for Certificates
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:jimsch5@home.com]
Sent: Thursday, December 21, 2000 2:56 PM
To: 'Al Arsenault'; ietf-pkix@imc.org
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