Re: [IETF-PKIX] New Notary Protocol Draft

[Rich Ankney <rankney@xxxxxxxxx>]

----------
> From: Robert Zuccherato <robert.zuccherato@entrust.com>
> To: 'IETF-PKIX@LISTS.TANDEM.COM'; 'rankney@erols.com'
> Subject: RE: [IETF-PKIX] New Notary Protocol Draft
> Date: Wednesday, March 11, 1998 9:55 AM
>
> Rich;
>
> Thanks for your comments.  My responses are below.
>
> >----------
> >From:        Rich Ankney[SMTP:rankney@erols.com]
> >Sent:        Tuesday, March 10, 1998 1:16 PM
> >To:  Robert Zuccherato; IETF-PKIX@LISTS.TANDEM.COM
> >Subject:     Re: [IETF-PKIX] New Notary Protocol Draft
> >
> >1.  Could we add an extension capability to the request and response?
>
> Yes, we certainly could.  Would something like the "extensions" field in
> v3 certificates be what you are looking for?  That can easily be added.
>
> I don't know if we need to define any specific extensions in this
> document, we could just let people define their own.  Any thoughts?

The extensions field from the v3 certificate would be fine.  We have some
application-specific things in mind, but I don't think they need to be
standardized.

> >
> >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.
>
> This is something I hadn't thought about before.  I don't know if I
> really see the utility of allowing this (presently only one signature is
> allowed).  Do you have a particular application in mind.

I was thinking of ANSI X9.45 and related standards in the healthcare
arena that use PKCS #7 (now CMS) SignedData with multiple
signatures quite extensively.  Granted, the most common case of
SignedData has just one SignerInfo, but I see no reason to preclude
the case where multiple SignerInfo's are present.

> >
> >3.  The relationship between request type, SignedData, and the embedded
> >data is a little murky.
>
> Yeah, the idea behind separating the two services was to allow one to
> get someone else's signature notarized (use the embedded data), but also
> to give a format for the requester to have just their possession of the
> data notarized, and to combine the services.  Any other thoughts on this
> would be appreciated.
>

I like the idea of separating the two services.  I just think the text
could
be a little clearer.  Having complained, I'll of course draft some text to
(hopefully) make things clearer.

> >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.
>
> Correct.
> >
> >   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".
>
> Not quite.  For npd, the data could be either "message",
> "messageImprint" or "cert".  For this service the Notary Authority
> doesn't examine the data, so it can be anything.  This service just
> provides evidence that the requester possessed the data (and the
> signature key) at that time.  The use of "messageImprint" allows this
> evidence to be produced for private data.  The utility of using "cert"
> in this situation is dubious, but it isn't disallowed.
>
> Also, for ns the data must be of type "message".  For this service the
> signature is contained in the "message", so it is not possible to use
> "messageImprint"

OK.  I get it now...

> >
> >4.  It might be good to mention some useful formats in the Message
> >structure, such as id-data and id-signedData.
>
> Certainly.  Are there any others that should be included.

Those are the only two I can think of right now.

> >
> >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.
>
> That is a very good idea.  Yes, it can.
> >
> >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?
>
> Yes, that is what we are trying to accomplish here.  If we are missing
> anything from the protocol that would allow this to happen, let me know.

I'll take a look at the X.509/PKIX path processing algorithm and see
what additional inputs/outputs are needed.  Question:  is the policy in
the NotaryRequest and NotaryResponse supposed to identify a
certificate policy?  It's not clear from the current text.


>
>       Robert.
> >

Regards,
Rich