[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt




Stefan/Santosh,

Jumping in mid-stream, but to fully specify what the client wants doesn't it need to specify the signing algorithm, the hashing algorithm, 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.

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.

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.

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?

spt


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 defined
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?

/Stefan


On 09-08-17 10:56 PM, "Santosh Chokhani" <SChokhani@xxxxxxxxxxxx> wrote:

Stefan,

First of all: That is what I have been saying: "The client needs to
specify the curve."

But, when you go to 5480, the curves are specified for the Alg ID in
SPKI.  If you look down at the ASN.1 for SIGNED MACRO type Alg ID, it
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 5480), we may need to
come up with different ASN.1."

-----Original Message-----
From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx]
Sent: Monday, August 17, 2009 4:47 PM
To: Santosh Chokhani
Cc: ietf-pkix@xxxxxxx
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt

Santosch,


On 09-08-17 10:39 PM, "Santosh Chokhani"
<SChokhani@xxxxxxxxxxxx> wrote:

Stefan,

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
the signature.

But the client can specify curve, and in that case the server
would know what the client wants, right?. That feels good
enough for me. I'm not sure what more you would suggest that we do?

/Stefan