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

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 12 Aug 2009 18:37:05 -0400

Stefan,

Thanks for addressing most of my concerns.  I have two partial concerns
remaining from old comments.  I have also recommended text for two
questions you had, but would like folks who specify Algorithm Identifier
ASN.1 to make sure they are ok with it.

There are no new comments below.

COMMENT 1
Section 2 states:

   "o  An implementation may intentionally wish to guard against the
      possibility of a compromise resulting from a signature algorithm
      compromise by employing two separate encryption algorithms."

This should be changed as follows: 
      
   "o  A PKI may wish to guard against the possibility of a compromise
resulting from a signature algorithm compromise by employing two
separate signature algorithms for CRL and OCSP signing, thus allowing
the relying parties to employ one mechanism or other for certificate
status validation."

COMMENT 2
Section 3, The Algorithm Identifier should be one asserted in SIGNED
MACRO or Signature field in order to cover hashing algorithms.

COMMENT 3
Section 3, Unlike SIGNED MACRO and Signature field, the Algorithm
Identifier can contain parameters for the client to declare its
constraints.  For example, a client who only processes Suite B curves
only may do so by using the following ASN.1 structure:

SEQUENCE {
	SEQUENCE {ecdsa-with-SHA256 OBJECT IDENTIFIER
		    secp256r1 OBJECT IDENTIFIER}
	SEQUENCE {ecdsa-with-SHA384 OBJECT IDENTIFIER
		    secp384r1 OBJECT IDENTIFIER}
	    }

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.

COMMENT 4
Section 7.2 should be revised to reference LTANS DSSC I-D to shield the
client against weak algorithms.  It is desirable that IETF standards
build on each other. 

Santosh Chokhani
CygnaCom Solutions

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 Aug 2009 09:57:32 +0200

Santosch,

Thanks for the clarifications. Comments in line.

> the relying parties to employ one mechanism or other for certificate

I have to disagree to this change. Your text may be correct in many
situations but I don't feel that it is meaningful for this draft. This is
just orientation text and the one that is currently present is IMO more
generic and accurate.

> MACRO or Signature field in order to cover hashing algorithms.

I think it is adequate to refer to the structure of section 4.1.1.2 of RFC
5280. I have added a reference.

> based on RFC 5480), we may need to come up with different ASN.1.

The definition of AlgorithmIdentifier in RFC 5280 which is consistent with
the X.509 SIGNED macro includes parameter:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

Is this not enough?

> client against weak algorithms.  It is desirable that IETF standards

First I want to avoid referencing an I-D and secondly I'm not convinced that
it is motivated in the context of this draft.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 Aug 2009 15:55:16 -0400

Stefan,

See responses in-line. 

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Monday, August 17, 2009 3:58 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> 
> Santosch,
> 
> > Thanks for addressing most of my concerns.  I have two partial 
> > concerns remaining from old comments.  I have also recommended text 
> > for two questions you had, but would like folks who specify 
> Algorithm 
> > Identifier
> I have to disagree to this change. Your text may be correct 
> in many situations but I don't feel that it is meaningful for 
> this draft. This is just orientation text and the one that is 
> currently present is IMO more generic and accurate.

[Santosh] OK.  I am fine with your statement.  Can you change
"encryption" to "signature".

> I think it is adequate to refer to the structure of section 
> 4.1.1.2 of RFC 5280. I have added a reference.

[Santosh] This is problematic in light of ongoing hash algorithms
discussion.  If public key algorithm asserted in SPKI is used, it will
not convey hashing algorithm.  As I recall, on the previous go around,
you asked for my advise.  Upon reflection, I think it needs to be the
one that conveys the hashing and signing algorithm.

> The definition of AlgorithmIdentifier in RFC 5280 which is 
> consistent with the X.509 SIGNED macro includes parameter:
> 

[Santosh] If we are concerned with algorithm agility and
interoperability, if an implementation does not recognize a EC curve
OID, we will not achieve the objective.  Here also you requested my
input.  But, more importantly, as we move to EC, named curves recognized
by the client do become an issue of interoperability.

> 
> 
> > COMMENT 4
> > Section 7.2 should be revised to reference LTANS DSSC I-D to shield 
> > the client against weak algorithms.  It is desirable that IETF 
> > standards build on each other.
> > 
> 
> First I want to avoid referencing an I-D and secondly I'm not 
> convinced that it is motivated in the context of this draft.

[Santosh  am ok with your decision. I am pointing this out since this is
the only effort I know in IETF where an implementation can guard against
invoking weak algorithm which may still be embedded in the
implementation.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 Aug 2009 22:19:33 +0200

Santosch,

I will change encryption to Signing.

As to the rest I may miss what you are saying.
I do agree that the algorithm identifier specified must be signature
algorithms (specifying both hash and signing algorithm).

With respect to ECC I'm not sure what you are missing.
I was under the impression that RFC5480 is adequate for providing
interoperability. RFC 5480 is compatible with the specified syntax. What
else do we need?

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 Aug 2009 16:39:36 -0400

Stefan,

Shall I assume that you will add a note on the type of Alg ID?

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.

> Sent: Monday, August 17, 2009 4:20 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> I do agree that the algorithm identifier specified must be 
> signature algorithms (specifying both hash and signing algorithm).
> 
> I was under the impression that RFC5480 is adequate for 
> providing interoperability. RFC 5480 is compatible with the 
> specified syntax. What else do we need?
> 
> /Stefan
> 
> >> situations but I don't feel that it is meaningful for this draft. 
> >> This is just orientation text and the one that is 
> currently present 
> consistent 
> >> with the X.509 SIGNED macro includes parameter:
> >> 
> > input.  But, more importantly, as we move to EC, named curves 
> > recognized by the client do become an issue of interoperability.
> > 
> >> 
> >> 
> >>> COMMENT 4
> > [Santosh  am ok with your decision. I am pointing this out 
> since this 
> > is the only effort I know in IETF where an implementation can guard 
> > against invoking weak algorithm which may still be embedded in the 
> > implementation.
> > 
> >> 
> >> /Stefan
> >> 
> >> 
> >>> 
> >>> Santosh Chokhani
> >>> CygnaCom Solutions
> >>> 
> >> 
> >> 
> >> 
> 
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 Aug 2009 22:46:33 +0200

Santosch,

> Shall I assume that you will add a note on the type of Alg ID?

Yes, I can do that.

> 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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 Aug 2009 16:56:28 -0400

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."

> Sent: Monday, August 17, 2009 4:47 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> > 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
> 
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 Aug 2009 23:16:16 +0200

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 Aug 2009 17:22:58 -0400

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

> Sent: Monday, August 17, 2009 5:16 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> 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
> 
> 
> > 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."
> > 
> >> 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
> >> 
> >> 
> >> 
> 
> 
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 Aug 2009 08:27:18 -0400

Stefan/Santosh,

Jumping in mid-stream, but to fully specify what the client wants 
doesn't it need to specify the signing algorithm, the hashing algorithm, 
  algorithms parameters and the key size?  If we need all four of these 
then I'd suggest AlgorithmIdentifier might not be the right mechanism 
for unsigned requests.

I say unsigned requests because if the request is signed then you'd know 
the signing and hashing algorithm from the signature as well as the 
parameters and key size from the certificate.  None of the signing 
algorithm parameters I am aware of include key size.  Almost all are NULL.

If you still wanted to use algorithm identifier for unsigned, then for 
the ECDSA algs you'd need to assume that the recommendations in RFC 5480 
are followed.  That is if you request ECDSA with no parameters in an 
algorithm identifier you know it's ECDSA, SHA-256, P-256, and 256-bit key.

I'm not sure how you infer the key size from sha256WithRSAEncryption or 
id-dsa-with-sha256?

Maybe the way ahead is to include the clients cert in the request?

spt

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 18 Aug 2009 09:48:50 -0400

Sean,

See responses below. 

> From: Sean Turner [mailto:[email-masked]] 
> Sent: Tuesday, August 18, 2009 8:27 AM
> To: Stefan Santesson
> Cc: Santosh Chokhani; [email-masked]
> Jumping in mid-stream, but to fully specify what the client 
> wants doesn't it need to specify the signing algorithm, the 
> hashing algorithm,
>   algorithms parameters and the key size?  If we need all 
> four of these then I'd suggest AlgorithmIdentifier might not 
> be the right mechanism for unsigned requests.

[Santosh] Since this is public key (vice private key) operation and
since it is normally done in software, I do not think key size is
required.  Note that we generally do not define key size for public key
in certificates either.  It is implicit in the structure.

> 
> I say unsigned requests because if the request is signed then 
> you'd know the signing and hashing algorithm from the 
> signature as well as the parameters and key size from the 
> certificate.  None of the signing algorithm parameters I am 
> aware of include key size.  Almost all are NULL.

[Santosh] Unless I do not read the I-D properly, this has nothing to do
with client signing requests.  It is a new request extension (and not a
request entry extension).  Request Vs request entry extension should be
clarified in the I-D (Seth also noted the ambiguity).

> 
> If you still wanted to use algorithm identifier for unsigned, 
> then for the ECDSA algs you'd need to assume that the 
> recommendations in RFC 5480 are followed.  That is if you 
> request ECDSA with no parameters in an algorithm identifier 
> you know it's ECDSA, SHA-256, P-256, and 256-bit key.

[Santosh] The ecdsa-with-SHA256 does not mean P-256.  RFC 5480 itself
has two other curves that can be used with it.  There could be other
curves since the RFC does not restrict you.

[Santosh] My suggestion is that it is appropriate to use the Alg ID and
assert the parameters in spite of RFC 5480.  My reasoning is as follows.
The ASN.1 permits it; we need it for interoperability; the RFC wants
them absent when asserting in Signature or SIGNED MACRO since getting
the parameters from those locations have proven to be vulnerable to
substitution attack (at least in degenerate cases); they definitely are
not authenticated.  But, the application in this I-D is different.
Since the whole structure is unauthenticated, there is no harm in
unauthenticated parameters as well. 

> 
> I'm not sure how you infer the key size from 
> sha256WithRSAEncryption or id-dsa-with-sha256?
> 
> > 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
> > 
> >

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 19 Aug 2009 12:28:13 +1000

I disagree. The ASN.1 DOES NOT support using the same object id in different instances of the AlgorithmIdentifier structure with different parameter syntaxes. The ASN.1 may allow ANY syntax for the parameters, but the assumption (or explicit constraint -- depending on your version of ASN.1) is that the syntax is defined by the preceding object id.

Some code will have tables mapping OID-to-parameter-syntax to automatically decode Alg.Id values. With Santosh's suggestion the code would need different tables depending on context: one table when decoding an Alg.Id in the PreferredSignatureAlgorithms type, and another table when decoding an Alg.Id in a Signature type. Yuck.

It looks like what is really needed is a rule for matching acceptable combinations of signature algorithm and signing key properties (key algorithm and key length). To do that properly requires a new matching rule with its own syntax.

P.S. field names usually (must?) start with lower-case letters in ASN.1 so PreferredSignatureAlgorithms should be "SEQUENCE { algorithms SEQUENCE OF Alg.Id. }".

James Manger
[email-masked]
Identity and security team — Chief Technology Office — Telstra

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 18 Aug 2009 22:46:17 -0400

Jim,

What do you recommend we do: Forego clients stating the curves or define
new OIDs? 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Manger, James H
> Sent: Tuesday, August 18, 2009 10:28 PM
> To: [email-masked]
> Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> 
> [Santosh] My suggestion is that it is appropriate to use the 
> Alg ID and assert the parameters in spite of RFC 5480.  My 
> reasoning is as follows.
> The ASN.1 permits it; we need it for interoperability; the 
> RFC wants them absent when asserting in Signature or SIGNED 
> MACRO since getting the parameters from those locations have 
> proven to be vulnerable to substitution attack (at least in 
> degenerate cases); they definitely are not authenticated.  
> But, the application in this I-D is different.
> Since the whole structure is unauthenticated, there is no 
> harm in unauthenticated parameters as well.
> 
> 
> I disagree. The ASN.1 DOES NOT support using the same object 
> id in different instances of the AlgorithmIdentifier 
> structure with different parameter syntaxes. The ASN.1 may 
> allow ANY syntax for the parameters, but the assumption (or 
> explicit constraint -- depending on your version of ASN.1) is 
> that the syntax is defined by the preceding object id.
> 
> Some code will have tables mapping OID-to-parameter-syntax to 
> automatically decode Alg.Id values. With Santosh's suggestion 
> the code would need different tables depending on context: 
> one table when decoding an Alg.Id in the 
> PreferredSignatureAlgorithms type, and another table when 
> decoding an Alg.Id in a Signature type. Yuck.
> 
> 
> It looks like what is really needed is a rule for matching 
> acceptable combinations of signature algorithm and signing 
> key properties (key algorithm and key length). To do that 
> properly requires a new matching rule with its own syntax.
> 
> 
> 
> P.S. field names usually (must?) start with lower-case 
> letters in ASN.1 so PreferredSignatureAlgorithms should be 
> "SEQUENCE { algorithms SEQUENCE OF Alg.Id. }".
> 
> 
> James Manger
> Identity and security team - Chief Technology Office - Telstra
>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 19 Aug 2009 14:47:35 +1000

> 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

---

From: Sean Turner <[email-masked]>
Date: Wed, 19 Aug 2009 08:47:57 -0400

> I disagree. The ASN.1 DOES NOT support using the same object id in different instances of the AlgorithmIdentifier structure with different parameter syntaxes. The ASN.1 may allow ANY syntax for the…

I agree with James here.  Algorithm Identifier does allow you to define 
an algorithm with what ever parameters you want, but you just can't 
stick more parameters on the ecdsa-with-* OID.  The OIDs have been well 
defined/registered in RFC 3278, RFC 3279, RFC 5480, 
draft-ietf-pkix-sha2-dsa-ecdsa, draft-ietf-smime-3278bis (in RFC 
editor's queue), and draft-ietf-smime-new-asn (with IESG) which all say 
either NULL or absent parameters (depending on the hash alg).

---

From: Sean Turner <[email-masked]>
Date: Wed, 19 Aug 2009 08:59:08 -0400

> or allow the OIDs from subjectPublicKeyInfo.algorithm as well signature OIDs.

This was where I was  going.

> [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

---

From: Sean Turner <[email-masked]>
Date: Wed, 19 Aug 2009 08:47:18 -0400

> in certificates either.  It is implicit in the structure.

I think it is a private key operation in that the client is asking the 
server to use a particular private key.  There then might arise the case 
when the server supports a key size which the client does not.  In this 
case the client needs to tell the server "hey only use a private key 
this big otherwise I can't verify your signature".  If we're assuming 
the servers/clients support a particular private key size, then we ought 
to say what that size is.

On a new topic: Another concern I have is that there's a DoS attack when 
the attacker sends a really big bogus signture and the client has to 
spend time figuring this out.  We had a long discussion about this on 
the SMIME list.  We added a security consideration in 
draft-ietf-smime-3851bis as follows:

  Receiving agents that validate signatures and sending agents that
  encrypt messages, need to be cautious of cryptographic processing
  usage when validating signatures and encrypting messages using keys
  larger than those mandated in this specification.  An attacker could
  send certificates with keys which would result in excessive
  cryptographic processing, for example keys larger than those mandated
  in this specification, which could swamp the processing element.
  Agents which use such keys without first validating the certificate
  to a trust anchor are advised to have some sort of cryptographic
  resource management system to prevent such attacks.

> clarified in the I-D (Seth also noted the ambiguity).

I understand this, my point really was that you need to fully specify 
the four choices or infer them.

> curves since the RFC does not restrict you.

There are 2 tables in RFC 5480.  The 1st lists the possibilities for 
ECDSA but the 2nd (on page 10) provides some RECOMMENDED key sizes, 
hashes, and curves for a given # of bits of security.  What I was saying 
is that if we use that table, then we could infer everything.  But, the 
group will need to agree to that.

> unauthenticated parameters as well. 

I disagree with this adding additional (see response to James' email).

I agree the parameters don't need to be authenticated.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 19 Aug 2009 11:10:07 -0400

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

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. 

> Sent: Wednesday, August 19, 2009 8:59 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> > 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 
> > 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
> 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.
> 
> 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
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Aug 2009 12:15:19 -0400

A
>...
>
>On a new topic: Another concern I have is that there's a DoS attack 
>when the attacker sends a really big bogus signture and the client 
>has to spend time figuring this out.  We had a long discussion about 
>this on the SMIME list.  We added a security consideration in 

I agree that analogous text would be appropriate here.

>>...
>hashes, and curves for a given # of bits of security.  What I was 
>saying is that if we use that table, then we could infer everything. 
>But, the group will need to agree to that.

I like referring to such tables as a way to keep things simple, and 
increase the likelihood of interoperability.

Steve

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 23 Aug 2009 16:52:58 -0600

It appears to me that what you really want to place in this location is what
has been defined as an SMIME Capability.

I am afraid that James is wrong when saying there is only one structure that
can be associated with an OID, the correct statement should be that for any
given location, only one structure can be associated with an OID.

If one were to use an S/MIME capability, then one can define a new parameter
structure where necessary to carry information that needs to be conveyed but
is not part of the standard signature algorithm structure.

I have not looked, so I don't know if the necessary S/MIME capability
structures where defined for ECC, but they should be easy to define if they
have not.  

Note that when I re-did the SCVP ASN.1 structures, I changed that to use an
S/MIME capability set of definitions for the requested signature algorithm,
thus this would be exactly the same type of thing.

(An S/MIME capability uses the same ASN.1 AlgorithmIdentifier structure, it
just has a different set of associated types with a given OID.)

Jim

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Sean Turner
> Sent: Tuesday, August 18, 2009 6:27 AM
> To: Stefan Santesson
> specify
> populating

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 23 Aug 2009 19:47:11 -0400

I am ok with either the S/MIME capabilities or the structure Sean
defined.

I just think that since this is algorithm agility and interoperability
related structure, ability convey public key algorithm, hashing
algorithm and parameter restrictions for EC should be used. 

> From: Jim Schaad [mailto:[email-masked]] 
> Sent: Sunday, August 23, 2009 6:53 PM
> To: 'Sean Turner'; 'Stefan Santesson'
> It appears to me that what you really want to place in this 
> location is what has been defined as an SMIME Capability.
> 
> I am afraid that James is wrong when saying there is only one 
> structure that can be associated with an OID, the correct 
> statement should be that for any given location, only one 
> structure can be associated with an OID.
> 
> If one were to use an S/MIME capability, then one can define 
> a new parameter structure where necessary to carry 
> information that needs to be conveyed but is not part of the 
> standard signature algorithm structure.
> 
> I have not looked, so I don't know if the necessary S/MIME 
> capability structures where defined for ECC, but they should 
> be easy to define if they have not.  
> 
> Note that when I re-did the SCVP ASN.1 structures, I changed 
> that to use an S/MIME capability set of definitions for the 
> requested signature algorithm, thus this would be exactly the 
> same type of thing.
> 
> (An S/MIME capability uses the same ASN.1 AlgorithmIdentifier 
> structure, it just has a different set of associated types 
> with a given OID.)
> 
> Jim
> 
> 
> >   algorithms parameters and the key size?  If we need all four of 
> > these then I'd suggest AlgorithmIdentifier might not be the right 
> > mechanism for unsigned requests.
> > 
> > I say unsigned requests because if the request is signed then you'd 
> > know the signing and hashing algorithm from the signature 
> as well as 
> > the parameters and key size from the certificate.  None of 
> the signing 
> > algorithm parameters I am aware of include key size.  
> Almost all are 
> > NULL.
> > 
> > the ECDSA algs you'd need to assume that the recommendations in RFC 
> > 5480 are followed.  That is if you request ECDSA with no 
> parameters in 
> > an algorithm identifier you know it's ECDSA, SHA-256, P-256, and 
> > 256-bit key.
> > 
> > > the curve. We could then also add text warning for the 
> consequences
> > if the
> > >> 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
> > >> these OIDs with parameters (e.g., based on RFC 5480), we 
> may need 
> > >>> 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
> > >>>
> > >>>
> > >>>
> > >
> > >
> > >
> 
> 
>

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 24 Aug 2009 11:40:51 +1000

> given location, only one structure can be associated with an OID.

At least SMIMECapability is not defined to be an AlgorithmIdentifier -- it is a separate type, with different field names, and different related CLASSs (SMIME-CAPS vs ALGORITHM). Consequently, using the same OID in these two types with different parameter structures is not as bad as using the same OID with different parameter structures in different instances of AlgorithmIdentifier (which is what I objected to).

Curiously, in RFC 3851 "S/MIME 3.1" section 2.5.2.1 (where the one SMIMECapability in the document is defined for RC2) much of the text is solely to remind the reader not to confuse the two parameter structures. A new OID for the new parameter structure may have been a less confusing solution.

draft-ietf-smime-new-asn1 defines lots of SMIMECapability values collated from various specs. I can only see two parameter structures: INTEGER holding a key length for RC2; and KeyWrapAlgorithm. KeyWrapAlgorithm is itself a SMIMECapability (or Alg.Id elsewhere in the same draft!!!). Effectively, it seems to be more OIDs with no other structures. SMIMECapabilities already combines different types of algorithms (signature algs, symmetric algs, key encipherment algs...) in a single list. It might have been more in keeping with this usage to include key wrap algs in this list directly, instead of as parameters of another algorithms.

James Manger

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Aug 2009 07:56:06 +0200

I have incorporated Sean's structure in draft 03 together with all other
recent updates. Due to an error in the submission tool it was sent for
manual submission but it will hopefully appear in a few days.

I think Sean's proposal provides the best solution. I would like to avoid
S/MIME Capabilities, as I understand it, since it just provides another way
to include AlgorithmIdentifier OIDs with their defined parameters. This
would be subject to the same discussion as the original structure as
signature algorithm OIDs are defined with an absent parameter structure.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Aug 2009 19:42:04 +0200

The new draft is now available:

http://www.ietf.org/id/draft-ietf-pkix-ocspagility-03.txt

/Stefan

On 09-08-24 7:56 AM, "Stefan Santesson" <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 24 Aug 2009 21:15:08 -0700

One only needs to have the parameters in the event that there is information that needs to be conveyed which is not "instance" data rather than global data.  Thus when you look at a block algorithm, one would not want to say - you must use a specific IV - making the set of parameters for an algorithm like AES not required when you want to specify support.

There is a difference if you were looking at algorithms such as RSA-PSS or RSA-OAEP where one would have the ability to say that different hash or mask functions are supported.  The question for ECC would be what should one be able to advertise as being supported, and what items everybody needs to be able to support (or are implicit in the OID value).  I have not really looked into this.

There is a strong reason to support using the same OID value for both the S/MIME capability and any other uses, it means that one does not need to keep a table of equivalencies and makes the code much easier.  We did very much stress the need to understand that the structures where different, however this was not a new problem we introduced at this point.  Consider the RSA algorithm where the same OID is used in different locations with different parameters.

> From: Manger, James H [mailto:[email-masked]]
> Sent: Sunday, August 23, 2009 6:41 PM
> To: Jim Schaad; [email-masked]
> Subject: RE: [pkix] I-D Action:draft-ietf-pkix-ocspagility-02.txt
> 
> structure that
> At least SMIMECapability is not defined to be an AlgorithmIdentifier --
> it is a separate type, with different field names, and different
> related CLASSs (SMIME-CAPS vs ALGORITHM). Consequently, using the same
> OID in these two types with different parameter structures is not as
> bad as using the same OID with different parameter structures in
> different instances of AlgorithmIdentifier (which is what I objected
> to).
> 
> Curiously, in RFC 3851 "S/MIME 3.1" section 2.5.2.1 (where the one
> SMIMECapability in the document is defined for RC2) much of the text is
> solely to remind the reader not to confuse the two parameter
> structures. A new OID for the new parameter structure may have been a
> less confusing solution.
> 
> 
> draft-ietf-smime-new-asn1 defines lots of SMIMECapability values
> collated from various specs. I can only see two parameter structures:
> INTEGER holding a key length for RC2; and KeyWrapAlgorithm.
> KeyWrapAlgorithm is itself a SMIMECapability (or Alg.Id elsewhere in
> the same draft!!!). Effectively, it seems to be more OIDs with no other
> structures. SMIMECapabilities already combines different types of
> algorithms (signature algs, symmetric algs, key encipherment algs...)
> in a single list. It might have been more in keeping with this usage to
> include key wrap algs in this list directly, instead of as parameters
> of another algorithms.
> 
> James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 24 Aug 2009 21:20:41 -0700

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

> Sent: Wednesday, August 19, 2009 5:59 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Santosh's
> think there
> curve OIDs
> field. This

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Aug 2009 08:02:48 -0400

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 25 Aug 2009 12:46:48 -0400

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.

> Sent: Tuesday, August 25, 2009 8:03 AM
> To: Jim Schaad
> 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
> 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
> > 
> > 
> >>> is an easy (or defined) way to match Alg.Id parameters, let alone 
> >>> the signature-vs-key Alg.Id. issue.
> >>>
> >> 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.
> >>>
> IDENTIFIER This 
> >>> is a list of values that the client can support in an OCSP
> >> response
> >>> 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
> >> 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
> > 
> > 
> > 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 25 Aug 2009 13:21:24 -0400

Stefan,

I am ok with it except I want Jim and others to weigh in on my
preference for using SMIME capabilities as opposed to defining a new
structure. 

> Sent: Monday, August 24, 2009 1:42 PM
> To: Santosh Chokhani; Jim Schaad; Sean Turner
> Cc: [email-masked]
> Subject: I-D Action:draft-ietf-pkix-ocspagility-03.txt
> 
> > I have incorporated Sean's structure in draft 03 together with all 
> > other recent updates. Due to an error in the submission tool it was 
> > sent for manual submission but it will hopefully appear in 
> a few days.
> > 
> > I think Sean's proposal provides the best solution. I would like to 
> > avoid S/MIME Capabilities, as I understand it, since it 
> just provides 
> > another way to include AlgorithmIdentifier OIDs with their defined 
> > parameters. This would be subject to the same discussion as the 
> > original structure as signature algorithm OIDs are defined 
> with an absent parameter structure.
> > 
> > /Stefan
> > 
> > 
> >> I just think that since this is algorithm agility and 
> >> interoperability related structure, ability convey public key 
> >> algorithm, hashing algorithm and parameter restrictions 
> for EC should be used.
> >> 
> >>> It appears to me that what you really want to place in 
> this location 
> >>> is what has been defined as an SMIME Capability.
> >>> 
> statement 
> >>> should be that for any given location, only one structure can be 
> >>> associated with an OID.
> >>> 
> >>> If one were to use an S/MIME capability, then one can 
> define a new 
> >>> parameter structure where necessary to carry information 
> that needs 
> >>> to be conveyed but is not part of the standard signature 
> algorithm 
> >>> structure.
> >>> 
> >>> capability structures where defined for ECC, but they 
> should be easy 
> >>> to define if they have not.
> >>> 
> >>> Note that when I re-did the SCVP ASN.1 structures, I 
> changed that to 
> >>> use an S/MIME capability set of definitions for the requested 
> >>> signature algorithm, thus this would be exactly the same type of 
> >>> thing.
> >>> 
> >>> structure, it just has a different set of associated types with a 
> >>> given OID.)
> >>> 
> >>> Jim
> >>> 
> >>> 
> >>>>> Anyway, for clarity, I understand your position that 
> you think the
> >>>> defined
> >>>>> On 09-08-17 10:56 PM, "Santosh Chokhani" 
> <[email-masked]>
> >>>> wrote:
> >>>>> 
> >>>>>> Stefan,
> >>>>>>

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Aug 2009 13:39:01 -0400

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 25 Aug 2009 13:57:32 -0400

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.

> Sent: Tuesday, August 25, 2009 1:39 PM
> To: Santosh Chokhani
> Cc: Jim Schaad; Stefan Santesson; [email-masked]
> 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:
> > 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.
> > 
> > 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.
> > 
> used in an 
> >> subject public key information. The parameters MUST be 
> present when 
> >> used in the algorithm identifier associated with a 
> signature value." 
> >> So in it
> >> trailerField.  There's no negotiation of parameters so the RFC 
> >> doesn't mention what to do in case the values aren't supported.
> >>
> >> 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?
> >> 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
> >>>
> >>>
> >>>>> Signatue.signatureAlgorithm.algorithm field -- from 
> most to least
> >>>> preferred.
> >>>> signature.  e.g., In this AlgorithmIdentifer 
> algorithm=ecdsa-with-
> >>>> sha256

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Aug 2009 15:09:00 -0400

> 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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 25 Aug 2009 15:15:58 -0400

Sean,

Thanks.

Should not the draft-ietf-smime-3278bis be revised?

Why would you not allow advertising curved and OIDs you recognize in
SMIME capabilities?

> Sent: Tuesday, August 25, 2009 3:09 PM
> To: Santosh Chokhani; Jim Schaad
> Cc: Stefan Santesson; [email-masked]
> > As Yogi would say, unless I misunderstand you, you are 
> > misunderstanding me.
> > 
> 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
> 
> >> 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:
> >>>>>>> compatible (a server expecting only signature OIDs 
> would simply
> >>>>>> ignore the
> >>>>>>> non-signature OIDs).
> >>>>>>>
> >>>>>>>
> >>>>>>> >From  : PreferredSignatureAlgorithms ::= SEQUENCE { 
> Algorithms
> >>>>>> SEQUENCE OF
> >>>>>>> Alg.Id. }

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Aug 2009 19:04:23 -0400

> 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

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 26 Aug 2009 10:42:34 -0400

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

> Sent: Tuesday, August 25, 2009 7:04 PM
> That's what I'm trying to figure out.  Note that this would 
> also require changes to draft-ietf-pkix-new-asn1.
> 
> 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
> 
> >> 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.
> identifier 
> >>>>>>>>> or allow the OIDs from 
> subjectPublicKeyInfo.algorithm as well
> >>>>>>>> signature OIDs.
> >>>>>>>>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 26 Aug 2009 13:22:32 -0700

Sean,

I think that I am lost on what is going on here.

The entire point of the new structure to allow the user to specify a set of algorithms that they support and understand.  

So my assumption is that if the signature parameters are "significant" to the class of signature, as oppose to the specific signature, then they are going to be specified by the client to the server.  For the case of RSA-PSS this means that the hashAlg, maskGenAlg and trailerField parameters need to be set and included.  The saltLength field is relevant only to a specific signature and would not need to be set.

If one specifies only the OID for RSA-PSS w/o parameters, one may get a hash algorithm, and thus a signature, that one does not support.  This means that there is a negotiation that is required on the parameters (it happens to be a take it or leave it negotiation).  Just the same as if one lists the different v1.5 RSA signature algorithm identifiers.

(Boy does this look exactly like S/MIME capabilities)

Jim

> Sent: Tuesday, August 25, 2009 5:03 AM
> To: Jim Schaad
> Cc: 'Santosh Chokhani'; [email-masked]
> > 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
> >
> >
> >>> My gut feeling is that a client providing a list of OIDs would
> cover
> >> the bulk
> it's
> >> being asked to do.  Use this algorithm here and this certificate to
> do
> >> it.
> >>
> >> spt
> >>
> >>> James Manger
> >
> >
> >

---

From: Sean Turner <[email-masked]>
Date: Thu, 27 Aug 2009 07:24:00 -0400

> If one specifies only the OID for RSA-PSS w/o parameters, one may get a hash algorithm, and thus a signature, that one does not support.  This means that there is a negotiation that is required on…

For the RSA-PSS case it is clear that we should include the parameters 
and we can do this with little impact because the SMIMECapabilities are 
  not defined.

The point I'm making is that some of the SMIMECapabilities for EC 
algorithms have been defined and we just can't add parameters with 
impacting some existing implementations.

spt