Hi Tom,
All three values for 'uri-authentication-supported' (including
the cleartext 'basic') make sense, because the 'ippfax:' URL
MUST use TLS (or SSL3, for compatibility) per Table 15 of
'uri-security-supported'.
But there is an error in Table 15 - it allows the Sender and
Receiver to support and use 'none' for security. This is
wrong. It violates the intent that 'ippfax:' URLs MUST
always use data integrity and MAY use data privacy (i.e.,
encryption of data contents and not just the integrity
hash).
If TLS is not used for an IPPFAX-like service, then the URL
MUST be an 'ipp:' URL and NOT an 'ippfax:' URL.
When we ask IANA for a new standard port for 'ippfax:' URLs,
we have planned to state that TLS/SSL3 MUST always be used
on those URLs. On previous IPPFAX telecons, we have considered
that the behavior COULD be just like 'https:' - that is, the TLS
session is always immediately started, not negotiated to start
via the HTTP 'Upgrade:' header.
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, December 11, 2001 9:22 PM
To: Gail Songer
Cc: IPP FAX DL (E-mail)
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 Dec 12 2001 - 12:19:53 EST