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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

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.

> -----Original Message-----
> From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx] 
> Sent: Monday, August 17, 2009 4:20 PM
> To: Santosh Chokhani
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> 
> 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
> 
> On 09-08-17 9:55 PM, "Santosh Chokhani" 
> <SChokhani@xxxxxxxxxxxx> wrote:
> 
> > Stefan,
> > 
> > See responses in-line.
> > 
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:stefan@xxxxxxxxxxx]
> >> Sent: Monday, August 17, 2009 3:58 AM
> >> To: Santosh Chokhani
> >> Cc: ietf-pkix@xxxxxxx
> >> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >> 
> >> Santosch,
> >> 
> >> Thanks for the clarifications. Comments in line.
> >> 
> >> 
> >> On 09-08-13 12:37 AM, "Santosh Chokhani"
> >> <SChokhani@xxxxxxxxxxxx> wrote:
> >> 
> >>> 
> >>> 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."
> >>> 
> >> 
> >> 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".
> > 
> >> 
> >> 
> >>> COMMENT 2
> >>> Section 3, The Algorithm Identifier should be one asserted
> >> in SIGNED
> >>> 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.
> > 
> > [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.
> > 
> >> 
> >>> 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.
> >>> 
> >> 
> >> 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?
> > 
> > [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.
> > 
> >> 
> >> /Stefan
> >> 
> >> 
> >>> 
> >>> Santosh Chokhani
> >>> CygnaCom Solutions
> >>> 
> >> 
> >> 
> >> 
> 
> 
>