Re: [IETF-PKIX] New Notary Protocol Draft

[Robert Zuccherato <robert.zuccherato@xxxxxxxxxxx>]

Rich;

>----------
>From:  Rich Ankney[SMTP:rankney@EROLS.COM]
>Sent:  Wednesday, March 11, 1998 12:42 PM
>To:    IETF-PKIX@LISTS.TANDEM.COM
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>----------
>> 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
>> >
>> >
>> >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.

Okay, fair enough.  I think we can allow multiple signers.
>
>> >
>> >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.

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

Presently the document says that the policy should indicate either the
policy under which the notarization is requested or the policy for which
the certificate validity is to be reported.  I could imagine actually
having two policy fields in the request and response, one for the
notarization policy and one for the certificate policy, if people
thought that would be useful.

        Robert.
>