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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

I am ok with Sean's suggestion that I repeat below: 

PreferredSignatureAlgorithm ::= SEQUENCE {
     sigIdentifier   AlgorithmIdentifier,
     certIdentifier  AlgorithmIdentifier OPTIONAL }
 
sigIdentifier is the identifier the client would like to see in the
signature.  certIdentifier is the identifier the client would like to
see in the server's certificate that the server uses to sign the OCSP
response. 

> -----Original Message-----
> From: Sean Turner [mailto:turners@xxxxxxxx] 
> Sent: Wednesday, August 19, 2009 8:59 AM
> To: Santosh Chokhani
> Cc: ietf-pkix@xxxxxxx
> 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
>