3 Aug 2012 12:08
Re: draft-pala-rea-ocsp-over-dns
Erwann Abalea <eabalea <at> gmail.com>
2012-08-03 10:08:11 GMT
2012-08-03 10:08:11 GMT
[Sending this to pkix <at> ietf too, as others might have ideas. I mentionned the fact that nothing permitted to specify parameters along with the hash function, and I'm seeing GOST-hashed OCSP requests in our responders since mid july]
Bonjour,
I'm not sure that DNSSEC is useful here. After all, OCSP is usually requested and sent in clear, the response is already signed. I don't know what could DNSSEC add in here that we're missing.
GOST (and not Ghost) R 34.11-94 is a hash algorithm based on the GOST 28147-89 block cipher. The former needs an initial value, the latter needs some S-Boxes. CryptoPro defined 2 sets of parameters (test and production) in RFC4357, and a NULL parameter designates the "production" parameters (if I correctly read the ASN.1 module, I'm not sure it's valid). There's no "DEFAULT" in the DigestAlgorithm definition, the parameters element is only declared "OPTIONAL", so no value is not a synonym of a NULL value.
2012/8/2 Massimiliano Pala <pala <at> nyu.edu>
Hello,
thanks for the clarification. I agree that an update for RFC4501 is not the best idea (although it does not give
the possibility to even specify dns vs dnssec, AFAIK).
For the Ghost.. I see your point. I thought that the ghost hash did not need parameters to be specified (is there
a default or you have to explicitly specify them all the time ?). That is an issue as specifying those types of
parameters might be unfeasible in a URI... for that, we might need to specify an additional extension to cover
that case. It might be the only possibility.. although I am sure people on the PKIX will just say "no" to another
extension..
Thanks again for the input.
Cheers,
Max
On 08/02/2012 05:44 PM, Erwann Abalea wrote:
Bonsoir,
Updating RFC4501 to add non-DNS information such as a hash algorithm is not a good idea, IMO. Unfortunately, accessLocation in the AIA extension is only a GeneralNames type, which leaves no place for a hash algorithm either. Some magic trick is necessary.
Regarding GOST, you've added some crypto-agility by allowing the CA to specify the hash algorithm to use when hashing the certificate. What is proposed is sufficient for classical algorithms (such as the SHA1/2 family), because these don't need any parameter. Russia is pushing for its set of GOST defined algorithms (block cipher, hash, signature), and these algorithms are mandatory in Russia (and maybe neighbours). Support for them have been added in DNSSEC, for example.
The fact is that the GOST block cipher and hash algo (built on top of block cipher) need some parameters. For the block cipher, the S-boxes; for the hash, the underlying block cipher S-boxes and an IV (initial internal state of the hash function). When used in a certificate, these parameters find their place in the AlgorithmIdentifier structure (with the SHA* families, parameters is set to NULL).
In your scheme, there's no place for parameters. So crypto-agility is not complete.
I agree that GOST crypto stuff sucks, but we have to deal with real world constraints :(
Anyways, who knows how will the soon-to-be-announced SHA3 be used? Maybe it'll also need parameters too?
Erwann.
_______________________________________________ pkix mailing list pkix <at> ietf.org https://www.ietf.org/mailman/listinfo/pkix
RSS Feed