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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

Stefan,

Yes.  It should work.

Below is a snippet from Page 16 of RFC 5480.  Note that we generally
recommend to not include parameters in Signature field or in SIGNED
MACRO (that is a topic for another discussion).  But, we may have found
a reason to use them (generic ASN.1 for Alg ID allows it) and in this
case it is useful since while MITM is possible, both client and server
know what they will do/accept.

 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }

   -- ECDSA with SHA-224
   -- Parameters are ABSENT

   ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
     ecdsa-with-SHA2(3) 1 }

   -- ECDSA with SHA-256
   -- Parameters are ABSENT

   ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
     ecdsa-with-SHA2(3) 2 }

   -- ECDSA with SHA-384
   -- Parameters are ABSENT
 

> -----Original Message-----
> From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx] 
> Sent: Monday, August 17, 2009 5:16 PM
> To: Santosh Chokhani
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> 
> 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
> >> 
> >> 
> >> 
> 
> 
>