Subject: Re: SMIME cert dist draft and X.509

From: Sean Turner <[email-masked]>
Date: Fri, 07 Jul 2000 12:52:01 -0400

Jim and Sharon,

The biggest concern I have is the duplication of certificates in directory and
finding certification path.  The CertificateSet, which is required to be present
in SMimeCertificatePublish object, is a set of certificates that MUST be
present.  It contains a "bucket-o-certs" for the user certificates and CA
certificates.  If we could replace it with a pointer to the user certificate and
CA certificates it would solve this duplication problem. PKIPath couldn't be
used because it too is not a pointer.  Could we use something like (hack my
ASN.1 as you please) the following instead of CertificateSet:

CertificatesForSMIME ::= SEQUENCE {
  sMIMEUserCertificate CertificateIdentifier,
  sMIMECACertificates  SEQUENCE OF CertificateIdentifier }

CertificateIdentifier ::= CHOICE {
  issuerAndSerialNumber     IssuerAndSerialNumber,
  subjectKeyIdentifier  [0] SubjectKeyIdentifier }

This would solve the problem of duplication and it would provide the certificate
path.  This won't solve the problem of backwards compatibility though.  So maybe
we could use the following instead of CertificateSet too:

CertificateForSMIME ::= CHOICE {
  actualCertificates    CertificateSet,
  -- For backward compatibility with Netscape and Microsoft code
  pointerToCertficates  CertificatesForSMIME }

Thoughts?

Other issues:

- Using SMIMECapabilities instead of supportAlgorithms

To be honest I don't have a preference.  supportAlgorithms is in X.500 but
SMIMECapabilities is in an RFC.  Both are implemented.

- Using attribute certificates to bind algorithm instead of SMIMECapabilities

I think while it should  be a goal to use attribute certificates to bind the
algorithms to the certificates I don't think we're there yet (some maybe but not
most).  We probably don't want to wait for everbody to implement attribute
certificates before implementing this mechanism.

Cheers,

spt

Jim Schaad wrote:

> Sharon,
>
> There were a number of limitations that are in X509 that I was trying to
> overcome with this draft:
>
> The supportedAlgorithms field was not used for two reasons, first I did not
> know about it when this started and secondly attribute certificates were not
> defined at the time the problem was addressed, thus they were not a part of
> every S/MIME application already.  The use of the SignedData structure means
> that we are re-using already existing code in every S/MIME application.
> (The exact same mechinism is used for transfering the information when
> sending a signed message between two entities.)
>
> Given that we are living in an LDAP world rather than an X509 world, using
> isser DNs of certificates to attempt to find an issuer certificate is an
> extremely difficult problem.  Add to this the questions of
> companies/individuals not publishing intermeadiate CA certificates or making
> them private (although the CRL might be available from a non-directory
> location) and I don't know that in the internet world that the certificate
> retrevial portion of path construction is viable.
>
> While I agree that this problem might have been better considered in the
> PKIX working group as the problem is universion, however the problem and the
> solution was first found by S/MIME developers and the chair of the group
> agreed that it was a reasonable problem to be put before the group.
> Additionally, the solution used some items that were defined by the working
> group in the S/MIME documents rather than in PKIX documents.  Lastly, the
> PKIX group is still very X509 directory centric in many of it's solutions
> while the S/MIME working group is extremely LDAP centric.  Thus what seems
> to be a problem for the S/MIME working group might not be a problem for the
> PKIX working group (such as finding CA certificates without an X509
> directory).
>
> Additionally please note that we have not solved the general path
> construction problem, we have only made it easier (since the holder of the
> certificate is in a better situation to build their own path) for the sender
> to avoid the problem.  In the event that the PKIX group came up with a
> viable method of doing path discovery then this draft can be revised so that
> the full path information was not required in the attribute even though
> there are situations (i.e. offline or non-directory location of the
> attribute) where it might be useful.
>
> jim schaad
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Sharon Boeyen
> Sent: Friday, June 02, 2000 11:42 AM
> To: [email-masked]'
> Subject: SMIME cert dist draft and X.509
>
> I am not a regular participant on this mailing list, and therefore lack the
> history behind this draft. However, as editor of X.509, I'm wondering why
> this draft invents new data structures for requirements that, after a very
> quick review, I think that X.509 already has standardized structures to
> support. From a 509 perspective, I certainly want to understand any
> shortcomings that specification has with respect to meeting the needs of the
> applications that use public-key certificates.
>
> Regarding SMimeCapabilities themeselves; was the supportedAlgorithms
> attribute from 509 considered? If so, were there specific shortcomings that
> it had? Note that it is defined in X.509 as an attribute. Attributes can be
> stored in
> directories as part of entries (with or without being digitally signed
> and/or encrypted), they can be transferred in application protocols, they
> can be included in public-key and attribute certificates.
>
> Regarding the requirement to tie a set of supported algorithms to a specific
> certificate; the construct defined in the Internet draft is semantically an
> attribute certificate. Was an X.509 attribute certificate considered and
> rejected? If so, what were its deficiencies? Note that there are a number of
> ways to identify the holder of an X.509 attribute certificate. One of those
> is the hash of a public-key certificate. An attribute certificate that
> contained the hash of a public-key certificate and the supportedAlgorithms
> attribute seems to provide the functionality you're looking for. If you want
> a construct that includes several iterations (i.e.  the set of algorithms
> for each public-key certificate), then the X.509 construct
> attributeCertificateAttribute seems to provide this because it is a
> multivalued attribute that contains values of the attributeCertificate
> construct. Again, these can be stored in directories, stored in files,
> transferred in application protocols etc.
>
> Regarding PKI path construction; this is an area where a number of different
> groups seem to be active. I'm curious why there would be an smime specific
> mechanism for this anyway, when if there really is a problem, its probably
> not unique
> to smime. PKIX seems like a better place to solve this problem. I'm not sure
> I really understand your proposed solution. Are you focused only on
> hierarchies or also addressing networked trust models? Why store the path
> with the subject's domain when its the relying party's domain where the
> information is needed. Why associate it with a user certificate at all,
> since the same path (less the user cert) can be reused for any user certs
> signed by the same CA? X.509 has a standard attribute called pkiPath that I
> think may satisfy the requirement. This attribute contains a sequence of
> CA-certificates and its intent is that it stores paths that are frequently
> used by the relying parties within the community of a given CA. As such, it
> can be used to reduce the number of network connections and directory (or
> other protocol) requests to external domains. It is intended to be an
> optional facility that may be useful in some environments, but not necessary
> in others.
>
> With respect to all of these, my view is that, if directories are being used
> as repositories for the information, then ALL public-key certificates issued
> to a user be stored in the userCertificate attribute of their directory
> entry. This eliminates the need for specialized application-specific tools
> on the relying party side to find application specific data. If there are
> enhanced mechansims that provide potential efficiencies in an application
> specific environment these
> should be optional enhancements and not eliminate the fundamental
> interoperability requirement to store information in a common place. I hold
> the same view with respect to the pkiPath attribute. If stored in a
> directory it should not eliminate the need to store information as defined
> in X.509 and profiled by PKIX in the crossCertificatePair and caCertificate
> attributes.
>
> I apologize in advance if, due to my lack of knowledge of the history of
> this spec, I'm asking questions that have been previously dealt with and
> closed, but felt I should at least ask, in the capacity of X.509 editor.
>
> FYI, if anyone needs to see the X.509 spec, they can obtain it in Word or
> pdf format from the following:
>
> ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/
>
> This text has been approved by ITU and is the 2000 edition of X.509,
> although many of things I mention were in the 1997 3rd edition text as well.
>
> Sharon
>
> Sharon Boeyen
> Entrust Technologies
> [email-masked]