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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

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