Hi Carl-Uno,
Here I disagree. We have simply reiterated the RFC 2246 (TLS) requirement
to support the one (reasonably) strong cipher suite and for RELIABLE
use in IPPFAX we have stated that negotiating down to weaker cipher
suites is illegal in IPPFAX. If someone wants to field an 'anonymous
public Fax-like machine using IPP', then they should simply publish
an 'ipp:' URL with whatever data integrity or lack of it.
But 'ippfax:' URLs should offer an iron-clad guarantee of data integrity.
Otherwise the Fax-like behaviour is lost.
Cheers,
- Ira McDonald
-----Original Message-----
From: Carl-Uno Manros [mailto:carl at manros.com]
Sent: Friday, January 04, 2002 3:03 PM
To: Hastings, Tom N; Gail Songer
Cc: IPP FAX DL (E-mail); ipp (E-mail)
Subject: RE: IPP> RE: IFX> RE: Receiver Requirements for Certificate
Tom,
We should not try to improve on, change, or restate the conformance
statements in the existing TLS standard.
I expect that anybody implementing TLS with IPPFAX will use one of the
existing TLS implementations and for us to change anything in the
conformance to TLS will only cause confusion.
Carl-Uno
Carl-Uno Manros
2657 Windmill Parkway #420
Henderson, NV 89074-3384, USA
Tel +1-702-617-9414
Fax +1-702-617-9417
Mob +1-310-251-7103
Email carl at manros.com
> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Hastings,
> Tom N
> Sent: Wednesday, January 02, 2002 4:11 PM
> To: Hastings, Tom N; Gail Songer
> Cc: IPP FAX DL (E-mail); ipp (E-mail)
> Subject: 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 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
>>>>