Re: [IETF-PKIX] New Notary Protocol Draft

[Rich Ankney <rankney@xxxxxxxxx>]

A few comments on the new draft:

1.  Could we add an extension capability to the request and response?

2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
thinking of the case where I send a message of type (CMS) signedData
which has multiple signerInfos attached.

3.  The relationship between request type, SignedData, and the embedded
data is a little murky.  I interpret it as the following:

   a)  All requests and responses are contained in SignedData.
   For the ns and nc cases, this need not actually contain a
   signature (SignerInfo); for npd and responses, it must contain
   one SignerInfo.

   b)  For npd, the data must be of type "message".  For ns, the data
   may be "message" or "messageImprint".  For nc, the data is "cert".

4.  It might be good to mention some useful formats in the Message
structure, such as id-data and id-signedData.

5.  Since I may have multiple signatures on a message, can the "cert"
option be extended to request status on multiple (signer) certificates?
E.g. something like:

        SEQUENCE {
                targets         SEQUENCE OF Certificate,
                chains          SEQUENCE OF Certificate }

where targets are what I want status for, and chains contains the
certificates needed to build the paths from targets to a trusted root.

6.  Should the notary be able to do full path validation per X.509 v3
(and PKIX-1)?  I.e. should the requester be able to pass the initial
policy set and other stuff to the notary, and receive the policy
qualifiers etc. back?

Regards,
Rich