> 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.
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]
James Manger
Attachment:
smime.p7s
Description: S/MIME cryptographic signature