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

["Santosh Chokhani" <[e-mail]>]

If there is impact on existing implementations, I am ok with a new
structure. 

> -----Original Message-----
> From: Sean Turner [mailto:[e-mail]] 
> Sent: Tuesday, August 25, 2009 7:04 PM
> To: Santosh Chokhani; Jim Schaad
> Cc: Stefan Santesson; [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> 
> Santosh Chokhani wrote:
> > Sean,
> > 
> > Thanks.
> > 
> > Should not the draft-ietf-smime-3278bis be revised?
> 
> That's what I'm trying to figure out.  Note that this would 
> also require changes to draft-ietf-pkix-new-asn1.
> 
> > Why would you not allow advertising curved and OIDs you 
> recognize in 
> > SMIME capabilities?
> 
> Most, if not all, of it is based on concerns about impacts on 
> existing implementations.  RFC 3278 included SMIMECapabilities for
> ecdsa-with-sha1 with NULL parameters.  According to RFC 3851, 
> those NULLs shouldn't have been there, but we didn't notice 
> this until we started draft-ietf-smime-3278bis.  We decided 
> not to change the parameters to absent for ecdssa-with-sha1 
> in draft-ietf-smime-3278bis because it's been out for a long 
> time and there may be implementations that would be impacted 
> by the change to absent parameters.
> 
> For the ecdsa-with-sha* algorithms (where * is 224->512) we 
> decided we'd do the right thing and just leave out the 
> parameter because there were few (if any) implementations.
> 
> If we're going to advertise the curve for ECDSA, then we 
> should probably also do the same thing for ECDH/ECMQV.  So 
> we'd need to tweak those parameters to include both a 
> KeyWrapAlgorithm and the curve.  This also impacts 
> implementations of ECDH and ECMQV that conform to RFC 3278.
> 
> I guess all I'm saying is that are some impacts that don't 
> just involve publishing a new ID.
> 
> spt
> 
> >> -----Original Message-----
> >> From: Sean Turner [mailto:[e-mail]]
> >> Sent: Tuesday, August 25, 2009 3:09 PM
> >> To: Santosh Chokhani; Jim Schaad
> >> Cc: Stefan Santesson; [e-mail]
> >> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>
> >> Santosh Chokhani wrote:
> >>> Sean,
> >>>
> >>> As Yogi would say, unless I misunderstand you, you are 
> >>> misunderstanding me.
> >>>
> >>> Let us say client wants to signal ECDSA for P256, P521 and
> >> RSA PSS for
> >>> SHA 224.  The S/MIME capabilities sent by the client will
> >> be as follows:
> >>> SEQUENCE {
> >>> 	SEQUENCE {ecdsa-with-SHA256 OID
> >>> 		    secp256r1 OID}  
> >>> 	SEQUENCE {ecdsa-with-SHA512 OID 
> >>> 		    secp521r1 OID}
> >>> 	SEQUENCE {id-RSASSA-PSS  OID
> >>> 		[0] sha224Identifier
> >>>             [1] mgf1SHA24Identifier
> >>>             [2] INTEGER 20
> >>>             [3] INTEGER 1  }	 
> >>> 		}
> >>>
> >>> So, you can simply use the signature algorithms and assert
> >> parameters,
> >>> as opposed to using separate OIDs.
> >> I guess I'm not getting it then.  My original concern is 
> that we've 
> >> got documents that already say what parameters are 
> associated with an 
> >> OID.
> >> For example, draft-ietf-smime-3278bis (with the RFC 
> editor) defines 
> >> SMIMECapabilities for the ECDSA algorithms.  The 
> capability is an OID 
> >> and parameters are absent.
> >>
> >> spt
> >>
> >>>> -----Original Message-----
> >>>> From: Sean Turner [mailto:[e-mail]]
> >>>> Sent: Tuesday, August 25, 2009 1:39 PM
> >>>> To: Santosh Chokhani
> >>>> Cc: Jim Schaad; Stefan Santesson; [e-mail]
> >>>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>>>
> >>>> Just so I understand, the proposal is to carry groupings 
> of algs.  
> >>>> One would be signature algorithms, one would be hashing
> >> algorithms,
> >>>> and another is the parameters (i.e., reuse the existing OIDs)?
> >>>>
> >>>> spt
> >>>>
> >>>> Santosh Chokhani wrote:
> >>>>> I have added Stefan to this.
> >>>>>
> >>>>> I suspect what Jim Schaad is alluding to the fact that
> >> for RSA PSS
> >>>>> signature algorithm contains the parameters.  Even in light
> >>>> of that,
> >>>>> the proposed ASN.1 structure will work.  The parameters can be 
> >>>>> repeated in the subject public key algorithm  also.  The
> >>>> relying party
> >>>>> (i.e., the OCSP Responder) can only use the parameters
> >> from subject
> >>>>> public key algorithm in all instances, including RSA PSS.
> >>>>>
> >>>>> So, either the S/MIME capability or the new ASN.1 work.
> >>>>>
> >>>>> That said, I have preference for S/MIME capability assuming
> >>>> Jim Schaad
> >>>>> is in agreement.  My rationale for the preference is that
> >> we should
> >>>>> not define new structures if we do not need to.  It also
> >> eliminates
> >>>>> the confusion in the case of PSS.
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Sean Turner [mailto:[e-mail]]
> >>>>>> Sent: Tuesday, August 25, 2009 8:03 AM
> >>>>>> To: Jim Schaad
> >>>>>> Cc: Santosh Chokhani; [e-mail]
> >>>>>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>>>>>
> >>>>>> Jim,
> >>>>>>
> >>>>>> RFC 4055 is the one ID that defines parameters for the 
> >>>>>> AlgorithmIdentifier.  From RFC 4055:  "When RSASSA-PSS is
> >>>> used in an
> >>>>>> AlgorithmIdentifier, the parameters MUST employ the
> >>>> RSASSA-PSS-params
> >>>>>> syntax.  The parameters may be either absent or present
> >>>> when used as
> >>>>>> subject public key information. The parameters MUST be
> >>>> present when
> >>>>>> used in the algorithm identifier associated with a
> >>>> signature value." 
> >>>>>> So in it
> >>>>>>   could still use the structure Stefan has in the most
> >>>> current draft.
> >>>>>> RSA-PSS parameters include hashAlg, maskGenAlg, 
> saltLength, and 
> >>>>>> trailerField.  There's no negotiation of parameters so the RFC 
> >>>>>> doesn't mention what to do in case the values aren't supported.
> >>>>>>
> >>>>>> I would think the ID should address the general case when
> >>>> the server
> >>>>>> doesn't support the requested algorithms/parameters and
> >>>> whatever we
> >>>>>> decide for that case should also apply to this one.
> >>>>>>
> >>>>>> spt
> >>>>>>
> >>>>>> Jim Schaad wrote:
> >>>>>>> Sean,
> >>>>>>>
> >>>>>>> What happens with RSA-PSS?  It has a set of parameters -
> >>>>>> are these parameters to be specified in the algorithm 
> identifier 
> >>>>>> field?  What happens with fields like salt length if they are 
> >>>>>> specified?  Must you honor that value even though the all
> >>>> values must
> >>>>>> be supported by validators?
> >>>>>>> Or is this really just suppose to be an OID and not have
> >>>>>> the parameters.  In this case one could not restrict the
> >>>> set of hash
> >>>>>> values used for RSA-PSS.  We did not define things like
> >>>> RSA-PSS-sha1.
> >>>>>>> Jim
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: [e-mail] [mailto:owner-ietf- 
> >>>>>>>> [e-mail]] On Behalf Of Sean Turner
> >>>>>>>> Sent: Wednesday, August 19, 2009 5:59 AM
> >>>>>>>> To: Santosh Chokhani
> >>>>>>>> Cc: [e-mail]
> >>>>>>>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Manger, James H wrote:
> >>>>>>>>>> What do you recommend we do: Forego clients stating the
> >>>>>> curves or
> >>>>>>>>>> define new OIDs?
> >>>>>>>>> or allow the OIDs from 
> subjectPublicKeyInfo.algorithm as well
> >>>>>>>> signature OIDs.
> >>>>>>>>
> >>>>>>>> This was where I was  going.
> >>>>>>>>
> >>>>>>>>> I have not thought about EC curves hard enough to
> >> really answer
> >>>>>>>> Santosh's
> >>>>>>>>> question.
> >>>>>>>>> A proper solution would get a bit complex, particularly
> >>>> as I don't
> >>>>>>>> think there
> >>>>>>>>> is an easy (or defined) way to match Alg.Id parameters,
> >>>> let alone
> >>>>>>>>> the signature-vs-key Alg.Id. issue.
> >>>>>>>>>
> >>>>>>>>> My gut feeling is that a client providing a list of OIDs
> >>>>>> would cover
> >>>>>>>> the bulk
> >>>>>>>>> of use cases, and the complexity to handle the rest is
> >>>>>> unlikely to
> >>>>>>>>> be worthwhile. I would specify a very simple syntax with no
> >>>>>>>>> parameter-
> >>>>>>>> based
> >>>>>>>>> matching.
> >>>>>>>>>
> >>>>>>>>> PreferredSignatureAlgorithms ::= SEQUENCE OF OBEJCT
> >>>>>> IDENTIFIER This
> >>>>>>>>> is a list of values that the client can support in an OCSP
> >>>>>>>> response
> >>>>>>>>> Signatue.signatureAlgorithm.algorithm field -- from
> >>>> most to least
> >>>>>>>> preferred.
> >>>>>>>>> If necessary in the future, you could allow SPKI alg OIDs
> >>>>>> and/or EC
> >>>>>>>> curve OIDs
> >>>>>>>>> in the same list. It would not really match the
> >>>> semantics of the
> >>>>>>>>> preferred-signature-algorithms extension, but it would be
> >>>>>> backwardly
> >>>>>>>>> compatible (a server expecting only signature OIDs
> >> would simply
> >>>>>>>> ignore the
> >>>>>>>>> non-signature OIDs).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> P.S. Why is PreferredSignatureAlgorithms a SEQUENCE
> >>>> with a single
> >>>>>>>> field. This
> >>>>>>>>> seems like an unnecessary extra SEQUENCE wrapping --
> >> unless you
> >>>>>>>>> might
> >>>>>>>> want to
> >>>>>>>>> extend the type later, adding more fields. However, in
> >>>> that case,
> >>>>>>>>> you
> >>>>>>>> would
> >>>>>>>>> probably just define a new extension.
> >>>>>>>>> Perhaps change
> >>>>>>>>> >From  : PreferredSignatureAlgorithms ::= SEQUENCE {
> >> Algorithms
> >>>>>>>> SEQUENCE OF
> >>>>>>>>> Alg.Id. }
> >>>>>>>>> to    : PreferredSignatureAlgorithms ::= SEQUENCE OF Alg.Id.
> >>>>>>>>> [or to: PreferredSignatureAlgorithms ::= SEQUENCE OF OBJECT
> >>>>>>>> IDENTIFIER]
> >>>>>>>>
> >>>>>>>> How about something like:
> >>>>>>>>
> >>>>>>>> PreferredSignatureAlgorithms ::= SEQUENCE OF 
> >>>>>>>> PreferredSignatureAlgorithm
> >>>>>>>>
> >>>>>>>> PreferredSignatureAlgorithm ::= SEQUENCE {
> >>>>>>>>    sigIdentifier   AlgorithmIdentifier,
> >>>>>>>>    certIdentifier  AlgorithmIdentifier OPTIONAL }
> >>>>>>>>
> >>>>>>>> sigIdentifier is the identifier the client would like to
> >>>>>> see in the
> >>>>>>>> signature.  e.g., In this AlgorithmIdentifer
> >>>> algorithm=ecdsa-with-
> >>>>>>>> sha256
> >>>>>>>> and parameters are absent.
> >>>>>>>>
> >>>>>>>> certIdentifier is the identifier the client would like to
> >>>>>> see in the
> >>>>>>>> server's certificate that the server uses to sign the OCSP
> >>>>>> response.
> >>>>>>>> e.g., In this AlgorithmIdentifier 
> algorithm=id-ecPublicKey and 
> >>>>>>>> parameters= secp256r1.
> >>>>>>>>
> >>>>>>>> certIdentifier is optional for those algs that don't need it.
> >>>>>>>>
> >>>>>>>> With this information the server would be able to easily
> >>>> tell what
> >>>>>>>> it's being asked to do.  Use this algorithm here and this
> >>>>>> certificate
> >>>>>>>> to do it.
> >>>>>>>>
> >>>>>>>> spt
> >>>>>>>>
> >>>>>>>>> James Manger
> > 
> 
> 
>