9. (2004-06-10, 10:02:50)rhousley

 > The protocol supports a single digital signature algorithm.  Since
 > no algorithm identifiers appear in any of the protocol data units,
 > it is not possible to support others in the future.  While I think
 > this is a poor design choice, I am not blocking the document on this
 > point.  However, I do insist that this situation be explained in the
 > document introduction.  I also insist that the name of the signature
 > option be changed.  The name needs to reflect the signature algorithm
 > so that it is clear that the mechanism to support other signature
 > algorithms is the definition of a new option.

Reply:

The algorithm identifier does appear in the protocol data units, its
just somewhat hidden in the CGA Option. In the CGA-signed messages, 
it is inside the ASN.1-encoded Public Key in the CGA Parameters field of 
the CGA Option. In the delegation-chain-based messages, the algorithm is
specified by the subjectPublicKeyInfo field in the final certificate.

There are two additional issues here:

1) Discussing why only a single cryptoalgorithm was chosen.

2) Renaming the signature algorithm to reflect that only one algorithm
    is supported.

Taking the issues in reverse, we will change the name of the signature
algorithm in Section 5.2 to "RSA Signature Option"

Regarding the first issue, we will add the following paragraph to
Section 1:

     RSA is mandated because having multiple signature algorithms would
     break compatibility between implementations or increase implementation
     complexity by forcing implementation of multiple algorithms and the
     mechanism to select among them.  A second signature algorithm is only
     necessary as a recovery mechanism, in case RSA is found to be
     insecure. If that happens, a stronger signature algorithm can be
     selected and SEND can be revised. The relationship between the new
     algorithm and the RSA-based SEND described in this document would be
     similar to that between the RSA-based SEND and Neighbor Discovery
     without SEND.  Information signed with the stronger algorithm has
     precedence over that signed with RSA, in the same way as RSA-signed
     information now takes precedence over unsigned
     information. Implementations of the current and revised specs would
     still be compatible.

---------------

Russ Housley:

> The algorithm identifier does appear in the protocol data units, its
> just somewhat hidden in the CGA Option. In the CGA-signed messages, 
> it is inside the ASN.1-encoded Public Key in the CGA Parameters field of 
> the CGA Option. In the delegation-chain-based messages, the algorithm is
> specified by the subjectPublicKeyInfo field in the final certificate.

The traditional approach is to associate a type with the public key,
which is done in the subjectPublickKeyInfo, and to associate a type
with the signature value, which is missing in the original document.
In the revisions described below, the signature type is implied by
the option identifier. In the traditional approach, the public
key is only used to attempt signature validation if the two types
are appropriate. This check is not discussed here, but it is
discussed in the response to comment 10.

> There are two additional issues here:
> 
> 1) Discussing why only a single cryptoalgorithm was chosen.
>
> 2) Renaming the signature algorithm to reflect that only one algorithm
>    is supported.
>
> Taking the issues in reverse, we will change the name of the signature
> algorithm in Section 5.2 to "RSA Signature Option"

Fine.

> Regarding the first issue, we will add the following paragraph to
> Section 1:
>
>   RSA is mandated because having multiple signature algorithms would
>   break compatibility between implementations or increase implementation
>   complexity by forcing implementation of multiple algorithms and the
>   mechanism to select among them.  A second signature algorithm is only
>   necessary as a recovery mechanism, in case RSA is found to be
>   insecure. If that happens, a stronger signature algorithm can be
>   selected and SEND can be revised. The relationship between the new
>   algorithm and the RSA-based SEND described in this document would be
>   similar to that between the RSA-based SEND and Neighbor Discovery
>   without SEND.  Information signed with the stronger algorithm has
>   precedence over that signed with RSA, in the same way as RSA-signed
>   information now takes precedence over unsigned
>   information. Implementations of the current and revised specs would
>   still be compatible.

Okay.

-------------

80 - Algorithm Identifier

Aura: Well hidden, part of ASN.1 encoded public key. Within CGA signed algorithm extension. 

Housley: Typed public key, but not signature.

Aura: Sec or implemetatin issue?

Housley: Proposed text overloads option identifier, so that it identifies algorithm, by name of option.

Aura: Single algorithm.

Housley: Text is OK

Action Item: Match option against public key, rename option. Text from proposal.