[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Algorithm revocation
On the "Algorithm revocation" concept, while an RP would probably not
always want to rely on a CA's ideas about which algorithms are unsafe, at
least it would allow a CA to notify RP software which predates an algorithm
compromise and isn't configurable for a list of weakened algorithms that it
has reason to believe that some algorithm is weakened. This idea is
actually more useful in having a CA which is a trusted root for some users
impose a constraint on CA's it has cross-certified than it is in simply
avoiding individual revocations, since a CA is expected to perform such
revocations as needed whether issuing a large number of revocations is
costly or not.
If you're going to provide revocation facilities for an algorithm in
this way, wouldn't it be better to allow for the possibility that an
algorithm is revoked for certain key lengths and not for others (e.g.,
RSA-512 may be broken while RSA-2048 is not)? If this is indeed a
reasonable idea, revokedAlgorithms would be a CRL extension (not a CRL
entry extension) with approximately the following syntax:
RevokedAlgorithmsSyntax ::= SEQUENCE OF CompromisedAlgorithm
CompromisedAlgorithm ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
minimumSafeKeyBits INTEGER DEFAULT 1000000000, -- or any very large
number
-- would a combination of { KeyUsage flag, Size } be more useful?
revocationDate Time,
explanatoryText UTF8String OPTIONAL
}
I don't see the point of having entry extensions inside
revokedAlgorithms, nor do I see any need to extend the base CRL structure
for them. The criticality of this extension as a whole is a matter of
opinion.
On multiple signatures, is it really wise to encourage the inclusion
of multiple CMS SignerInfo's or equivalents as an extension to an OCSP
responses? I know that there are some non-repudiation situations where
this might be of slightly greater use than having the RP choose its desired
signature algorithm using a requestExtension, while being more efficient
than asking for the same answer multiple times with such an extension and
getting multiple identical response bodies with different signatures.
However, signed timestamp pyramiding ought to protect against later
compromises of algorithms which are not believed to be questionable at the
time of the OCSP check.
Tom Gindin
Sönke Maseberg <maseberg@xxxxxxxxxxxxxxxx> on 02/19/2001 04:27:48 PM
To: pkix <ietf-pkix@xxxxxxx>
cc:
Subject: multiple digitale signatures
Hello,
we are working at the problem, that it couldn't be excluded that one
component of a public key infrastructure can be compromised, since no
proofable secure signature algorithm or hash function exists.
For example nowadays the hash functions SHA-1 or RIPEMD-160 and the
signature algorithms RSA with 1024 bit or ECDSA with 160 bit keylength
are qualified for cryptographic purposes. The public key cryptograpy is
based on mathematical problems which are supposed to be hard to solve,
but it is not known for sure. If a failure occurs the security of the
PKI could not be guaranteed any longer as a whole, this means the
electronic communication may be insecure.
That is the reason why we develop a public key infrastructure which will
keep its functionality in the case of failure and which is able to be
repaired and where generated digital signatures won't lose their
proofability.
As a basic restriction the technical components must be integrated in
the PKI in such a flexible manner, that an exchange could be possible.
The flexible public key infrastructure which is developed at the chair
of Professor Buchmann of the Technical University of Darmstadt/Germany
in the "FlexiPKI" project is following this philosophy.
The main idea is to build up a public key infrastructure upon several
independent cryptographic components, where in the case, one component
is compromised the other components still can be used to:
- Exchange the compromised component securely
- Sign electronic documents multiple (concept of multiple digital
signatures)
To support standards of PKIX, we ask for some discussions about our
ideas and extensions:
1. multiple digital signatures
We want to use multiple digital signatures, that are digital signatures
generated of independent signature algorithms, for example RSA with
SHA-1 and ECDSA with RIPEMD-160. PKCS#7 supports those signatures. But
we would like to extend OCSP responses [RFC 2560] and CRLs (Certificate
and CRL Profile) [<draft-ietf-pkix-new-part1-04.txt>] with multiple
digital signatures in the following manner:
OCSP response:
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL,
additionalsignatures [1] SEQUENCE OF SEQUENCE { --
EXTENSION
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
} OPTIONAL
}
CRL:
CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING,
additionalsignatures SEQUENCE OF SEQUENCE { --
EXTENSION
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
} OPTIONAL
}
2. revoked algorithms
If a signature algorithms is compromised, all certificates have to be
revoked. But the number of those certificates can be very large, so we
would like to revoke an algorithm. For this reason we propose the
following extension of CRL (Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]:
TBSCertList ::= SEQUENCE {
version Version OPTIONAL,
signature SEQUENCE OF AlgorithmIdentifier, --
EXTENSION
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
} OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL,
revokedAlgorithms [1] SEQUENCE OF SEQUENCE { --
EXTENSION
signatureAlgorithm AlgorithmIdentifier,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
} OPTIONAL
}
What do you think about it?
Thanks in advance,
Sönke
---
Sönke Maseberg GMD - Institut für Sichere Telekooperation
Dipl.-Math. Rheinstr. 75, D-64295 Darmstadt
Tel: 06151/869-60036, Fax: 06151/869-224
Technische Universität Darmstadt
Institut fuer Theoretische Informatik
Lehrstuhl Prof. J. Buchmann
Alexanderstr. 10, D-64283 Darmstadt