IPP> RE: IFX> RE: Receiver Requirements for Certificate

IPP> RE: IFX> RE: Receiver Requirements for Certificate

IPP> RE: IFX> RE: Receiver Requirements for Certificate

Hastings, Tom N hastings at cp10.es.xerox.com
Wed Jan 2 19:11:28 EST 2002


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 at 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 at 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 at cp10.es.xerox.com>@pwg.org on 12/11/2001
07:22:03 PM

Sent by:  owner-ifx at pwg.org


To:   Gail Songer <gsonger at netreon.com>
cc:   "IPP FAX DL (E-mail)" <ifx at 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 at 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







More information about the Ipp mailing list