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

[Stefan Santesson <stefan@xxxxxxxxxxx>]

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