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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

Sean,

See responses below. 

> -----Original Message-----
> 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
> 
> 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.

[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 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).

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

[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'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
> >>>
> >>>
> >>>
> > 
> > 
> > 
>