[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Santosh Chokhani wrote:
See responses below.
From: Sean Turner [mailto:turners@xxxxxxxx]
Sent: Tuesday, August 18, 2009 8:27 AM
To: Stefan Santesson
Cc: Santosh Chokhani; ietf-pkix@xxxxxxx
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Jumping in mid-stream, but to fully specify what the client
wants doesn't it need to specify the signing algorithm, the
algorithms parameters and the key size? If we need all
four of these then I'd suggest AlgorithmIdentifier might not
be the right mechanism for unsigned requests.
[Santosh] Since this is public key (vice private key) operation and
since it is normally done in software, I do not think key size is
required. Note that we generally do not define key size for public key
in certificates either. It is implicit in the structure.
I think it is a private key operation in that the client is asking the
server to use a particular private key. There then might arise the case
when the server supports a key size which the client does not. In this
case the client needs to tell the server "hey only use a private key
this big otherwise I can't verify your signature". If we're assuming
the servers/clients support a particular private key size, then we ought
to say what that size is.
On a new topic: Another concern I have is that there's a DoS attack when
the attacker sends a really big bogus signture and the client has to
spend time figuring this out. We had a long discussion about this on
the SMIME list. We added a security consideration in
draft-ietf-smime-3851bis as follows:
Receiving agents that validate signatures and sending agents that
encrypt messages, need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages using keys
larger than those mandated in this specification. An attacker could
send certificates with keys which would result in excessive
cryptographic processing, for example keys larger than those mandated
in this specification, which could swamp the processing element.
Agents which use such keys without first validating the certificate
to a trust anchor are advised to have some sort of cryptographic
resource management system to prevent such attacks.
I say unsigned requests because if the request is signed then
you'd know the signing and hashing algorithm from the
signature as well as the parameters and key size from the
certificate. None of the signing algorithm parameters I am
aware of include key size. Almost all are NULL.
[Santosh] Unless I do not read the I-D properly, this has nothing to do
with client signing requests. It is a new request extension (and not a
request entry extension). Request Vs request entry extension should be
clarified in the I-D (Seth also noted the ambiguity).
I understand this, my point really was that you need to fully specify
the four choices or infer them.
If you still wanted to use algorithm identifier for unsigned,
then for the ECDSA algs you'd need to assume that the
recommendations in RFC 5480 are followed. That is if you
request ECDSA with no parameters in an algorithm identifier
you know it's ECDSA, SHA-256, P-256, and 256-bit key.
[Santosh] The ecdsa-with-SHA256 does not mean P-256. RFC 5480 itself
has two other curves that can be used with it. There could be other
curves since the RFC does not restrict you.
There are 2 tables in RFC 5480. The 1st lists the possibilities for
ECDSA but the 2nd (on page 10) provides some RECOMMENDED key sizes,
hashes, and curves for a given # of bits of security. What I was saying
is that if we use that table, then we could infer everything. But, the
group will need to agree to that.
[Santosh] My suggestion is that it is appropriate to use the Alg ID and
assert the parameters in spite of RFC 5480. My reasoning is as follows.
The ASN.1 permits it; we need it for interoperability; the RFC wants
them absent when asserting in Signature or SIGNED MACRO since getting
the parameters from those locations have proven to be vulnerable to
substitution attack (at least in degenerate cases); they definitely are
not authenticated. But, the application in this I-D is different.
Since the whole structure is unauthenticated, there is no harm in
unauthenticated parameters as well.
I disagree with this adding additional (see response to James' email).
I agree the parameters don't need to be authenticated.
I'm not sure how you infer the key size from
sha256WithRSAEncryption or id-dsa-with-sha256?
Maybe the way ahead is to include the clients cert in the request?
Stefan Santesson wrote:
Where is it stated that parameters must be absent?
I tried to find it but failed.
It sounds strange as they are defined by the alg OID.
Anyway, for clarity, I understand your position that you think the
ASN.1 syntax is OK if we add a note saying that the client SHOULD
specify the curve. We could then also add text warning for the
consequences if the client does not specify the curve.
Would that work?
On 09-08-17 10:56 PM, "Santosh Chokhani"
First of all: That is what I have been saying: "The client
Alg ID in
specify the curve."
But, when you go to 5480, the curves are specified for the
Alg ID, it
SPKI. If you look down at the ASN.1 for SIGNED MACRO type
says parameters are absent. That is why note at the start of this
thread on ocspagility-02 and I quote "If we have argument on
populating these OIDs with parameters (e.g., based on RFC
may need to come up with different ASN.1."
From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx]
Sent: Monday, August 17, 2009 4:47 PM
To: Santosh Chokhani
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
On 09-08-17 10:39 PM, "Santosh Chokhani"
Shall I assume that you will add a note on the type of Alg ID?
Yes, I can do that.
As to 5480, it has lot of curves in it. If a client did
not ask for a
curve and server used one of these curves, the client may not
understand the curve and hence will not be able to process
But the client can specify curve, and in that case the
enough for me.
know what the client wants, right?. That feels good
I'm not sure what more you would suggest that we do?