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

[Stefan Santesson <stefan@xxxxxxxxxxx>]

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.


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

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


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

/Stefan


> 
> Santosh Chokhani
> CygnaCom Solutions
>