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

[Sean Turner <[e-mail]>]

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
>