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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

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