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

 > Since the document only supports RSA PKCS#1 v1.5 signatures, section 6.2
 > ought to discuss the processing of subjectPublicKeyInfo within the
 > certificate to ensure that only RSA public keys are used to attempt the
 > validation of signatures.

Reply:

We will add the following text to Section 6.2.6, end of paragraph 3:

     Hosts MUST check the subjectPublicKeyInfo field within the last
     certificate in the certificate path to ensure that only RSA public
     keys are used to attempt validation of router signatures, and MUST
     disregard the certificate for SEND if it does not contain an RSA key.

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

 > RFC 3280 uses the term "certification path," not the term "certificate
 > chain." Likewise, RFC 3280 uses the term "certification authority," not
 > the term "certificate authority."  Please align with RFC 3280.

Reply:

We will change it.

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

 > Please change "PKCS#1 signature" to "PKCS#1 v1.5 signature"
 > throughout the document.

Reply:

Agree.

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

 > In at least two places the document talks about ASN.1, and in another
 > place it talks about DER.  Normative references are needed.

Reply:

We will add references.

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

 > In the 2nd bullet of section 4, the document says:
 >
 > > This specification also allows a node to use non-CGAs with
 > > certificates to authorize their use.  However, the details of
 > > such use are beyond the scope of this specification.

 > The point that this topic is out of scope ought to come much earlier in
 > the document, preferably in the introduction.

Reply:

We will add the following paragraph at the end of Section 1:

     Out of scope for this document is the use of identity certificates
     provisioned on end hosts for authorizing address use, and security of
     ND when the entity defending an address is not the same as the entity
     claiming that adddress (also known as "proxy ND"). These are
     extensions of SEND that may be treated in separate documents should
     the need arise.

Russ Housley: Okay.

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

 > In section 5.2.2, the introduction of the "valid authorization delegation
 > chain" has no foundation.  Please include a forward reference to section 6.
 >
 > In section 6.2, last paragraph: s/must be a subset/MUST be a subset/

Reply:

Agree, we'll change the text.

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

 > In section 6.2.3, the document says:
 >
 > > When the Name Type field is set to 1, the Name field contains a
 > > DER encoded X.501 certificate Name, represented and encoded
 > > exactly as in the matching X.509v3 trust anchor certificate.
 >
 > However, a trust anchor need not have a certificate.  It must have a
 > X.501 name to be used in the issuer field of certificates that it issues,
 > but the use of a self-signed certificate is not required.

Reply:

Suppose we change the sentence to:

     ...exactly as in the issuer field of certificates that the
     certification authority issuing the public key issues

Russ Housley: I am not happy with this one.  See my comments in
response to comment number 4.  If it is not clear, come back to me.