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 : Thu Dec 13 2001 - 13:48:00 EST