IFX Mail Archive: RE: IFX> RE: Receiver Requirements for Cer

IFX Mail Archive: RE: IFX> RE: Receiver Requirements for Cer

RE: IFX> RE: Receiver Requirements for Certificate

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Jan 02 2002 - 19:11:28 EST

  • Next message: McDonald, Ira: "RE: IPP> RE: IFX> RE: Receiver Requirements for Certificate"

    More clarifications about Certificate requirements in IPPFAX. The IPPFAX
    Drafts have the following statement after Table 16 about cipher suites that
    MUST be supported:

    Senders and Receivers MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
    cipher suite as mandated by RFC 2246 [RFC2246]. All stronger cipher suites
    are OPTIONAL; weaker cipher suites MUST NOT be supported or used by Senders
    or Receivers.

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Thursday, December 13, 2001 10:48
    To: Gail Songer
    Cc: IPP FAX DL (E-mail); ipp (E-mail)
    Subject: RE: IFX> RE: Receiver Requirements for Certificate

    Gail,

    Here is what "certificate" means:

    In short TLS client authentication using a certificate as specified in the
    TLS standard.

    (Whenever a Receiver supports TLS, the Receiver MUST have its own
    certificate which it exchanges as part of TLS. See TLS spec and IPPFAX
    Table 16.)

    However, TLS [RFC2246] seems to allow a lot of different kinds of Server
    certificates (and client certificates) that depend on Key Exchange Algorithm
    and Certificate Key Type. So maybe your question is:

    a. whether IPPFAX is making some subset of the possible TLS certificates
    REQUIRED in order to improve interoperability?

    b. or does TLS require that all types of certificates be supported, so this
    isn't an issue?

    c. or do the standard TLS libraries support all of the types, so this isn't
    an issue?

    From RFC2246, section 7.4.2. Server certificate:

           Key Exchange Algorithm Certificate Key Type

           RSA RSA public key; the certificate must
                                   allow the key to be used for encryption.

           RSA_EXPORT RSA public key of length greater than
                                   512 bits which can be used for signing,
                                   or a key of 512 bits or shorter which
                                   can be used for either encryption or
                                   signing.

           DHE_DSS DSS public key.

           DHE_DSS_EXPORT DSS public key.

           DHE_RSA RSA public key which can be used for
                                   signing.

           DHE_RSA_EXPORT RSA public key which can be used for
                                   signing.

           DH_DSS Diffie-Hellman key. The algorithm used
                                   to sign the certificate should be DSS.

           DH_RSA Diffie-Hellman key. The algorithm used
                                   to sign the certificate should be RSA.

       All certificate profiles, key and cryptographic formats are defined
       by the IETF PKIX working group [PKIX]. When a key usage extension is
       present, the digitalSignature bit must be set for the key to be
       eligible for signing, as described above, and the keyEncipherment bit
       must be present to allow encryption, as described above. The
       keyAgreement bit must be set on Diffie-Hellman certificates.

    Here is what the IPP and IPPFAX specs say about certificates:

    From [RFC 2911] 4.4.2 uri-authentication-supported (1setOf type2 keyword)

    This REQUIRED Printer attribute MUST have the same cardinality (contain the
    same number of values) as the "printer-uri-supported" attribute. This
    attribute identifies the Client Authentication mechanism associated with
    each URI listed in the "printer-uri-supported" attribute. The Printer object
    uses the specified mechanism to identify the authenticated user (see section
    8.3). The "i th" value in "uri-authentication-supported" corresponds to the
    "i th" value in "printer-uri-supported" and it describes the authentication
    mechanisms used by the Printer when accessed via that URI. See [RFC2910]
    for more details on Client Authentication.

    'certificate': When a client performs an operation whose target is the
    associated URI, the Printer object expects the client to provide a
    certificate. The Printer object assumes that the authenticated user is the
    textual name contained within the certificate.

    From IPPFAX, section 11.1:

    11.1 Privacy

    Any exchange between a Sender and a Receiver MUST be carried using the
    privacy mechanism specified in IPP/1.1 namely TLS [RFC2246]. In some cases
    this will also result in mutual authentication of the Sender and Receiver
    (in the case where both sides have certificates).

    The Receiver MAY have a TLS certificate.
    [TH COMMENT: If we change 'none' back to MUST NOT in Table 13 as discussed
    in ISSUE 04, then the Receiver MUST have a TLS certificate, so we should
    change the MAY to a MUST in this sentence and probably add, since the
    Receiver MUST support and use TLS.]

    The Sender MAY have a certificate. A Receiver MAY decide to reject requests
    that come from Senders that do not have a certificate and return the
    'client-error-not-authenticated' status code.

    A Sender can either use its own certificate or it can use one associated
    with the Sending User.

    Senders and Receivers SHOULD do what current browsers do, namely, be
    deployed with the public keys of a number of the top Certificate
    Authorities. If a Sender gets a public key from a Receiver that it doesn't
    recognize, the Sender MUST query the Sending User to see if the Sending User
    trusts the Receiver before sending the IPPFAX job to the Receiver.

    The distribution of private keys to Senders or Receivers is outside the
    scope of this document, but it is done over the network, it MUST be over a
    secure channel. See Internet Key Exchange (IKE) [RFC2409].

    Gail,

    Does the above extracts from the specs make it clear what "certificate"
    means? After all, the point of the review is to make sure that the specs
    are clear and we are all getting the same understanding from them.

    Tom

    -----Original Message-----
    From: Gail Songer [mailto:gsonger@netreon.com]
    Sent: Wednesday, December 12, 2001 09:33
    To: Hastings, Tom N
    Cc: IPP FAX DL (E-mail)
    Subject: Re: IFX> RE: Receiver Requirements for Certificate

    Hi Tom,

    I was just unsure what "certificate" really ment.

    Gail

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 12/11/2001
    07:22:03 PM

    Sent by: owner-ifx@pwg.org

    To: Gail Songer <gsonger@netreon.com>
    cc: "IPP FAX DL (E-mail)" <ifx@pwg.org>

    Subject: IFX> RE: Receiver Requirements for Certificate

    Table 13 Authentication Requirements in section 11.2
    uri-authentication-supported says that a Receiver MUST support and MAY use:

    basic
    digest
    certificate

    Does this seem reasonable? If not, then lets raise it as an ISSUE.

    Tom

    -----Original Message-----
    From: Gail Songer [mailto:gsonger@netreon.com]
    Sent: Thursday, November 29, 2001 14:15
    To: Hastings, Tom N
    Subject: RE: Certificate

    Tom,

    Table 13 states that a receiver must support "Digest" and "Certificate". I
    was wondering what we are requiring the receiver to support.

    Gail



    This archive was generated by hypermail 2b29 : Wed Jan 02 2002 - 19:12:00 EST