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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

Jim,

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

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Manger, James H
> Sent: Tuesday, August 18, 2009 10:28 PM
> To: ietf-pkix@xxxxxxx
> 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
> James.H.Manger@xxxxxxxxxxxxxxxx
> Identity and security team - Chief Technology Office - Telstra
>