Subject: Re: Holder

From: "Tom Gindin/Watson/IBM" <[email-masked]>
Date: Wed, 15 Nov 2000 19:11:48 -0500

I don't have a specific example of an AC accompanying a signed
document or transaction, either with or without a PKC.  In fact, AFAIK
there is no place in either CMS or XMLDSIG to put an AC, although AC's
could go into the attributes (signed or unsigned) in CMS and into
SignatureProperty in XMLDSIG.  It is legal to specify an X509Data in
XMLDSIG which does not contain the full PKC (see section 4.4.4 of
http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/), and it is legal to
omit a PKC from SignedData in CMS (see section 5.1 of RFC 2630) "if it is
expected that recipients have an alternate means of obtaining necessary
certificates".
     I am suggesting that these are reasonable places for an AC to go in a
push scenario.  However, I am not personally involved in any current
development of software using AC's, so anyone who wishes to dismiss my
opinions on these matters as pure theory may do so.

          Tom Gindin

Steve Hanna <[email-masked]> on 11/14/2000 02:57:58 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: Holder

Do you have a specific example where an AC whose Holder component was
tied to a PKC would accompany a signed document (or other object) but
the PKC would not? This seems somewhat unlikely to me.

I don't mind recommending format 9 instead of format 5, based only on
easier debugging and a suspicion that the entityName might some day be
useful for finding the PKC. But I would be more comfortable if we had a
specific scenario where the entityName is needed to find the PKC.

-Steve

Tom Gindin/Watson/IBM wrote:
>
>      The primary use I can think of for format 7, 9, or 11 is to permit
an
> AC to accompany (or simply be stored with) a signed document,
transaction,
> or message without requiring the PKC to do so.  The RP can then look up
the
> PKC.  As I have stated before, in any case like this format 11 or format
9
> is preferable to format 5.  Formats 4 and 5 are appropriate when the PKC
> accompanies the AC or precedes it in a protocol, but not otherwise.
>      Since format 9 (or format 11) is preferable to format 5 when the AC
is
> sent or stored independently of the PKC and also carries out all the
> functions of format 5, I would replace your references to format 5 by
> references to format 9 (or format 11).  Formats 2, 4, and 9 make a
> reasonable minimal set, as do 2, 4, and 11.
>
>           Tom Gindin
>
> Steve Hanna <[email-masked]> on 11/10/2000 10:56:55 AM
>
> To:   [email-masked]
> cc:
> Subject:  Re: Holder
>
> Well, my list of scenarios does not seem to be helping us resolve this
> issue.
>
> I will make a specific proposal, seeking comments or consensus. Since
> none of the scenarios demonstrates a need for hints in Holder formats
> that include the objectDigestInfo component, I propose that we adopt the
> following recommendation, which would be incorporated into the next
> version of ac509 (along with text explaining the various formats, how
> they must be handled for validation purposes, and why each one might be
> preferred to the others).
>
>    AC issuers SHOULD use only formats 2, 4, or 5. They MAY use other
>    formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
>    5 (subject to specific requirements and configuration). They MAY
>    support other formats.
>
> I welcome comments from others on this proposal. A good argument can be
> made for replacing format 5 with format 9, if only for debugging
> purposes. But I'd rather not recommend support for both, if possible.
>
> -Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Nov 2000 11:07:58 +0100

Tom,

> document or transaction, either with or without a PKC.  

Such a case is described in:
http://www.imc.org/draft-ietf-smime-esformats

This document, called "Electronic Signature formats", explains (among other
things) how to attach an AC to a signed document or transaction. It is being
progressed in the S/MIME working group and reflects the work being performed
by ETSI on that topic.

> In fact, AFAIK
> SignatureProperty in XMLDSIG.  

An extension to support that property is described in the document.

Denis

> It is legal to specify an X509Data in

---

From: Steve Hanna <[email-masked]>
Date: Wed, 22 Nov 2000 11:14:18 -0500

Apparently, we cannot rule out the possibility that someone might want
to use an AC whose holder field was tied to a PKC without also providing
the associated PKC.

In that case (and given the debugging benefits of format 9 over format
5), let's go with formats 2, 4, and 9. Here is my revised proposal:

I propose that the following text be incorporated into the next version
of ac509 (along with text explaining the various formats, how they must
be handled for validation purposes, and why each one might be preferred
to the others).

   AC issuers SHOULD use only formats 2, 4, or 9. They MAY use other
   formats, as necessary. AC verifiers SHOULD support formats 2, 4, and
   9 (subject to specific requirements and configuration). They MAY
   support other formats.

Any objections? Agreement? General consensus?

-Steve

P.S. I am proposing this change at this late date (after IETF Last Call
has closed) to address the security risks Polar pointed out when using
format 2 (entityName only) with a potentially inconsistent namespace.