Subject: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

From: Sam Hartman <[email-masked]>
Date: Sun, 22 Jan 2006 18:51:29 -0500 (EST)

Hi.  I'd like to request the editors to issue a -33 including these
changes.  The number of changes are very small.  This document has
come a long way in the 8 years I've been following it.  Thanks for all
who have contributed.

Section 1:

I agree with Martin.  Please avoid non-repudiation as a term.  I think
the security service that matters in the introduction is data origin
authentication.

In section 3.1.1 remove extraneous "if present," from the last
paragraph:

old:

   In addition, implementations of this specification MUST be capable of
   processing the Extended Key Usage (EKU) extension and the id-pkinit-
   san (as defined in Section 3.2.2) otherName of the Subject
   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
   present.

new:

   In addition, implementations of this specification MUST be capable of
   processing the Extended Key Usage (EKU) extension and the id-pkinit-
   san (as defined in Section 3.2.2) otherName of the Subject
   Alternative Name (SAN) extension in X.509 certificates [RFC3280].

Section 3.1.3 seems to need alignment against the specs that are
being normatively referenced.

For example, rsaEncryption is an OID that in the PKCS specifications
specifies an RSA key.  How does this get used by pkinit.  It is
neither an RSA encryption operation norn a signature operation.

For each Kerberos enctype please explicitly specify the OID  and
source of that OID that the presence of the enctype implies is
supported.

In section 3.2, what are the cms encryption types in supportedCMSTypes
used for?  Are they just algorithms for encrypting the SignedData in
the EnvelopedData or does this list also include algorithms for
encrypting the temporary key in the public key?

In section 3.2.2, text regarding name binding seems to be wrong:

     If the KDC does not have its own binding and there is no
     KRB5PrincipalName name present in the client's X.509 certificate, or
     if the Kerberos name in the request does not match the
     KRB5PrincipalName in the client's X.509 certificate (including the
     realm name), the KDC MUST return an error message with the code
     KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
     this error message.

The problem with this text is that it appears to assume that the
binding name is in the certificate. I propose replacing "if the Kerberos name in the request does not match the
     KRB5PrincipalName in the client's X.509 certificate," with "if
the Kerberos name in the request does not match a  name bound by the
KDC or found in the certificate."

What does the following in the instructions for clients receiving
replies mean?

     Implementation note: CAs issuing KDC certificates SHOULD place all
     "short" and "fully-qualified" Kerberos realm names of the KDC (one
     per GeneralName [RFC3280]) into the KDC certificate to allow maximum
     flexibility.

In section 4:

The following text should be moved to a more appropriate place in the
document:

     The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
     permit empty SEQUENCEs to be encoded.  Such empty sequences may only
     be used if the KDC itself vouches for the user's certificate.

In addition, a standard comment about generating good random data
needs to be added with the appropriate reference  (RFC 4086?)

Section 7.1:

The reference to 4121 should be at most informative.  I believe that
4120 successfully defines newer so you should not need to refer to
4121.

I need to remember to last call and note normative down references to:

   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
              RFC 2412, November 1998.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

Appendix b:

Will someone assert that they have tested these test vectors and
confirmed they work?

---

From: Sam Hartman <[email-masked]>
Date: Sun, 22 Jan 2006 19:31:37 -0500

One other thing.  I understand that Jeff Altman and Gregory are in a
discussion of adding some language warning about things you might do
that would be a problem in FIPS implementations.

I do not object to this change being added in -33 if there is WG
consensus.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 22 Jan 2006 19:56:01 -0500 (EST)

Speaking as an individual, except where noted otherwise....

> encrypting the temporary key in the public key?

Actually, I think we're going overboard with listing algorithms in this
document.  For certificates and X.509 certificates, we should be leaving
the question of what algorithms exist entirely up to those specifications;
it is appropriate for us to specify which algorithms are REQUIRED and to
specify a negotiation mechanism, but except for the enctype definitions,
section 3.1.3 seems entirely superfluous to me, and possibly actually
harmful -- it implies that algorithm OID's not listed are not used by
PKINIT, and thus that the corresponding algorithms MUST NOT be used.  This
specification should not need to be updated to take advantage of new
algorithms defined for CMS.

It has always been my impression that the Kerberos enctypes defined in
this section were intended to be used in exactly the same way as
supportedCMSTypes, and that the presence of one of these enctypes in the
client's supported-enctypes list would have the same effect as if the
corresponding OID had been present in supportedCMSTypes.  I hope this is
sufficiently clear.

I agree that the current text is insufficiently clear about the meaning
of supportedCMSTypes.  It is unclear to me whether this needs to cover the
public-key algorithm used to encrypt the temporary key, since I would
expect that algorithm to be tightly bound to the public key in the
client's certificate.  But maybe that's not the case; given the list of
algorithms mentioned in section 3.1.3 and for which enctypes are defined,
and particularly the enclusion of rsaEncryption in that list, it would
seem that it was intended that both symmetric and public-key algorithms be
listed, and in fact that perhaps it was intended that public-key signing
algorithms also be listed (for used in SignedData?).

It seems to me that if supportedCMSTypes is not already intended to be
used this way, then at some point in the future we will need to extend the
semantics of this field or add a new field to support negotiation of
public-key algorithms supported by the client.

>      per GeneralName [RFC3280]) into the KDC certificate to allow maximum

That's a good question  I don't know what "short" and "fully-qualified"
realms names are, and neither does RFC4120.  According to that document:

   The following additional constraints apply to
   the assignment of realm names in the domain and X.500 categories:
   either the name of a realm for the domain or X.500 formats must be
   used by the organization owning (to whom it was assigned) an Internet
   domain name or X.500 name, or, in the case that no such names are
   registered, authority to use a realm name MAY be derived from the
   authority of the parent realm.  For example, if there is no domain
   name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
   authorize the creation of a realm with that name.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 02:05:39 -0800

By now, I have suggested text. See attached.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Sunday, January 22, 2006 4:32 PM
To: [email-masked]
Subject: Re: AD review comments on
draft-ietf-cat-kerberos-pk-init-32.txt

Subject: RE: secdir review: draft-ietf-cat-kerberos-pk-init-30.txt
From: "Liqiang\(Larry\) Zhu" <[email-masked]>
To: "Jeffrey Altman" <[email-masked]>, "Jeffrey Hutzelman" <[email-masked]>
Cc: "Gregory M Lebovitz" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Sam Hartman" <[email-masked]>
Date: Mon, 23 Jan 2006 02:03:09 -0800

 Jeffrey Altman wrote:
"Using such keys to wrap data encrypted under stronger conventional
cryptosystems does not conform to the best current practices outlined
in RFC3766."

First, I do not understand why it is inappropriate to wrap data
encrypted in stronger symmetric keys, it is no worse than sending it in
clear, right?

Secondly, RFC3766 does not say it is inappropriate to protect strong
symmetric keys with weak public keys, it just says the overall strength
of the system is no stronger than the weakest keys.

Thirdly I dislike the word "conventional".

So how about "When using such weak asymmetric keys to protect/exchange
stronger symmetric
Keys, the attack resistant strength of the overall system is no better
than that of these weak keys [RFC3276]."

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Wednesday, January 18, 2006 10:17 PM
To: Jeffrey Hutzelman
Cc: Gregory M Lebovitz; Liqiang(Larry) Zhu; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Sam Hartman
Subject: Re: secdir review: draft-ietf-cat-kerberos-pk-init-30.txt

Jeffrey Hutzelman wrote:

>>>>          - 2nd para on pg 25, last sentence - not only
"inappropriate"
>>>> but will not conform to certain industry-mandated standards, like 
>>>> FIPS 140.
>>>
>>> Not to mention RFC3766, to which we refer.  Do you think a stronger 
>>> statement is needed than is currently in the document?
>>
>> Yes, that's what I meant. Be supper explicit so people know how 
>> important it is.
> 
> OK.  Someone want to propose text?
> 
> 
> -- Jeff

How about?

"Using such keys to wrap data encrypted under stronger conventional
cryptosystems does not conform to the best current practices outlined in
RFC3766."

Jeffrey Altman

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 03:49:08 -0800

Sam Hartman wrote:
> I agree with Martin.  Please avoid non-repudiation as a term.  I think the security service that matters in the introduction is data origin 
> authentication.

I object. Non-repudiation is described in RFC3280, in a normative reference of PKINIT, I do not understand why it is hard to swallow. Non-repudiation is one of the most significant features that symmetric crypto systems can not achieve.

> In section 3.1.1 remove extraneous "if present," from the last

Done

 Sam Hartman wrote:
> Section 3.1.3 seems to need alignment against the specs that are being normatively referenced.

> For example, rsaEncryption is an OID that in the PKCS specifications specifies an RSA key.  How does this get used by pkinit.  It is neither an RSA 
> encryption operation norn a signature operation.

rsaEncryption is used in the type AlgorithmIdentifier, I can see it is not clear since RFC3477 defines its own AlgorithmIdentifier structure, but PKINIT imports it from RFC3280. 

Here is the relevant section in RFC3477.

A.1 RSA key representation

   This section defines ASN.1 object identifiers for RSA public and
   private keys, and defines the types RSAPublicKey and RSAPrivateKey.
   The intended application of these definitions includes X.509
   certificates, PKCS #8 [46], and PKCS #12 [47].

   The object identifier rsaEncryption identifies RSA public and private
   keys as defined in Appendices A.1.1 and A.1.2.  The parameters field
   associated with this OID in a value of type AlgorithmIdentifier shall
   have a value of type NULL.

   rsaEncryption    OBJECT IDENTIFIER ::= { pkcs-1 1 }

   The definitions in this section have been extended to support multi << cut>>

However RFC3279 seems to have come for rescue:

Section 2.3.1 of RFC3279 says:

   The rsaEncryption OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier.  The parameters field MUST
   have ASN.1 type NULL for this algorithm identifier.

Therefore to clarify this, I would suggest to replace

OLD:

   PKINIT uses the following encryption algorithm identifiers as defined
   in [RFC3447] for encrypting the temporary key with a public key:

NEW:

   PKINIT uses the following encryption algorithm identifiers as defined
   in [RFC3447] [RFC3279] for encrypting the temporary key in the encryptedKey
   field of the member KeyTransRecipientInfo [RFC3852] with a public
   key, as described in Section 3.2.3.2:

 Sam Hartman wrote:
> For each Kerberos enctype please explicitly specify the OID  and source of that OID that the presence of the enctype implies is supported.

I do not think I understand what you meant here.

 Sam Hartman wrote:
> In section 3.2, what are the cms encryption types in supportedCMSTypes used for?  Are they just algorithms for encrypting the SignedData in the > 
> EnvelopedData or does this list also include algorithms for encrypting the temporary key in the public key?

Are these different things? I thought they are the same.

 Sam Hartman wrote:
>  The problem with this text is that it appears to assume that the binding name is in the certificate. I propose replacing "if the Kerberos name in the 
> request does not match the
>     KRB5PrincipalName in the client's X.509 certificate," with "if the Kerberos name in the request does not match a  name bound by the KDC or found in > the certificate."

I agree with you that the current text is inaccurate, but I suggest a small change to your text, so the new text would look as follows:

"If the Kerberos client name in the AS-REQ does not match a name bound by the KDC 
(the binding can be in the certificate, for example as described above), or if there is no binding 
found by the KDC, the KDC MUST return an error message with the code
   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
   this error message."

So this would cover the case where there is no binding. What do you think?

Jeff Hutzman wrote:

> Actually, I think we're going overboard with listing algorithms in this document.  For certificates and X.509 certificates, we should be leaving the 
> question of what algorithms exist entirely up to those specifications; it is appropriate for us to specify which algorithms are REQUIRED and to specify 
> a negotiation mechanism, but except for the enctype definitions, section 3.1.3 seems entirely superfluous to me, and possibly actually harmful -- it 
> implies that algorithm OID's not listed are not used by PKINIT, and thus that the corresponding algorithms MUST NOT be used.  This specification should > not need to be updated to take advantage of new algorithms defined for CMS.

The problem is in the first pragraph of sectin 3.1.3,

I suggest to replace, 

OLD:

   PKINIT does not define, but does make use of, the following algorithm
   identifiers.

NEW:
  
   In order to promote interoperability, algorithm object identifiers 
   listed in this section MUST be supported by conforming 
    implementations.

This way it is clear that implementations can take advantage of new algorithms defined for CMS/X.509 certificates without waiting for the update of this specification. Note I emphasize the OIDs need to be suported, thus excluding the kerberos etype 9-15 as described in this section.

Jeff Hutzman wrote:

> I agree that the current text is insufficiently clear about the meaning of supportedCMSTypes.  It is unclear to me whether this needs to cover the 
> public-key algorithm used to encrypt the temporary key, since I would expect that algorithm to be tightly bound to the public key in the client's 
>  certificate.  But maybe that's not the case; given the list of algorithms mentioned in section 3.1.3 and for which enctypes are defined, and 
> particularly the enclusion of rsaEncryption in that list, it would seem that it was intended that both symmetric and public-key algorithms be listed, 
> and in fact that perhaps it was intended that public-key signing algorithms also be listed (for used in SignedData?).

> It seems to me that if supportedCMSTypes is not already intended to be used this way, then at some point in the future we will need to extend the > 
> semantics of this field or add a new field to support negotiation of public-key algorithms supported by the client.

To me, supportedCSMTypes can contain a set of the following: des-ede3-cbc, rc2-cbc, id-aes256-CBC. And nothing else for now.  So let's replace

OLD

       The supportedCMSTypes field specifies the list of CMS
       encryption types supported by the client in order of (decreasing)
       preference.

NEW:
  
       The supportedCMSTypes field specifies the list of CMS
       encryption types that are supported by the client in order of (decreasing)
       preference, and can be used in the keyEncryptionAlgorithm field of 
       the type KeyTransRecipientInfo [RFC3852] when encrypting the AS reply key
       as described in Section 3.2.3.2.

>   authorize the creation of a realm with that name.

The short name would be E40 in this case, this usage is typcial in our deployment, where users tend to type in the short names whenever possible.

It does not make sense to allow shortnames in dNSHost SAN, but it might make sense to allow short-form of the realm names in the krb5Principal names, as the most typcial scenarios are in intranet, a controlled environment. What do you think?

>     be used if the KDC itself vouches for the user's certificate.

It is moved to section 3.2.3.

Sam wrote:
> In addition, a standard comment about generating good random data needs to be added with the appropriate reference  (RFC 4086?)

The following is added in the security consideration section:

 <t>   The security of cryptographic algorithms 
   is dependent on generating secret quantities <xref target="RFC4086"/>.  The number of truly random bits is extremely important
   to determining the attack resistance strength of the cryptosystem, 
   for example, the secret Diffie-Hellman exponents must be
   chosen based on n truly random bits (where n is the system security requirement). 
   The security of the overall system is significantly weakened by using insufficient
   random inputs:  a sophisticated attacker may find it easier to reproduce
   the environment that produced the secret quantities and to search the
   resulting small set of possibilities than to locate the quantities in
   the whole of the potential number space.</t>

What do you think?

>  Section 7.1:
> The reference to 4121 should be at most informative.  I believe that 4120 successfully defines newer so you should not need to refer to 4121.

The word "newer" is clarified in RFC4121. it is not entirely clear which encryption type is "newer" based on rfc4120 alone.

> Will someone assert that they have tested these test vectors and confirmed they work?

Love confirmed that these vectors were good.

Please verify these changes in the attached -33. thanks.

-- Larry

--

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Sunday, January 22, 2006 3:51 PM
To: [email-masked]
Subject: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

Hi.  I'd like to request the editors to issue a -33 including these changes.  The number of changes are very small.  This document has come a long way in the 8 years I've been following it.  Thanks for all who have contributed.

Section 1:

I agree with Martin.  Please avoid non-repudiation as a term.  I think the security service that matters in the introduction is data origin authentication.

old:

new:

Section 3.1.3 seems to need alignment against the specs that are being normatively referenced.

For example, rsaEncryption is an OID that in the PKCS specifications specifies an RSA key.  How does this get used by pkinit.  It is neither an RSA encryption operation norn a signature operation.

For each Kerberos enctype please explicitly specify the OID  and source of that OID that the presence of the enctype implies is supported.

In section 3.2, what are the cms encryption types in supportedCMSTypes used for?  Are they just algorithms for encrypting the SignedData in the EnvelopedData or does this list also include algorithms for encrypting the temporary key in the public key?

The problem with this text is that it appears to assume that the binding name is in the certificate. I propose replacing "if the Kerberos name in the request does not match the
     KRB5PrincipalName in the client's X.509 certificate," with "if the Kerberos name in the request does not match a  name bound by the KDC or found in the certificate."

What does the following in the instructions for clients receiving replies mean?

In section 4:

In addition, a standard comment about generating good random data needs to be added with the appropriate reference  (RFC 4086?)

Section 7.1:

The reference to 4121 should be at most informative.  I believe that 4120 successfully defines newer so you should not need to refer to 4121.

Appendix b:

Will someone assert that they have tested these test vectors and confirmed they work?

---

From: Brian Tung <[email-masked]>
Date: Mon, 23 Jan 2006 08:47:18 -0800

Liqiang(Larry) Zhu wrote:
> I object. Non-repudiation is described in RFC3280, in a normative
> reference of PKINIT, I do not understand why it is hard to swallow.
> Non-repudiation is one of the most significant features that symmetric
> crypto systems can not achieve.

I do think that non-repudiation is being achieved.  I wonder if it is an
important achievement of PKINIT, though.  The other parties in the
authentication sequence do not make use of the non-repudiation, do they?
That is to say, their acceptance of the TGT is based on the KDC's
acceptance of the user's credentials, not on the user's inability to
repudiate their request.  For that reason, perhaps, it is more important
to highlight the origin authentication in PKINIT, rather than the
non-repudiation, even though that is a more difficult property to
achieve.

-- 
Brian Tung <[email-masked]>
USC Information Sciences Institute

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Jan 2006 10:54:30 -0600

> >      per GeneralName [RFC3280]) into the KDC certificate to allow maximum

If the intention is to support matching KDCs by non-fully-qualified
query strings, then: a) I don't see why one should need to do that at
all, b) I don't see how having the "short" names in the cert helps --
the client can always just take a short form name, and a search list of
domain name qualifiers and see if short.qualifierN matches any of the
FQDNs in the cert.

Note that matching non-fully-qualified names to FQDNs is a problem that
does need solving -- users like non-FQDNs, but I don't think users
normally type in KDC names, and anyways, this isn't really the place to
solve that problem.

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 11:37:49 -0800

Nothing is said about what PKINIT has achieved, what I tried to say is
why people choose to use asymmetric keys instead of symmetric keys, and
for that non-repudiation and prefect secrecy made the cut.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Tung
Sent: Monday, January 23, 2006 8:47 AM
To: [email-masked]
Subject: Re: AD review comments on
draft-ietf-cat-kerberos-pk-init-32.txt

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 11:40:48 -0800

Nicolas Williams wrote:
>   and a search list of domain name qualifiers and see if
short.qualifierN matches any of the FQDNs in the cert.

Exactly where do I get the domain name qualifier list? This is unlike
the qualifer list for hostnames, when I "net use" from a machine in a
different forest, (excuse for the use of MS terminology).

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Monday, January 23, 2006 8:55 AM
To: Jeffrey Hutzelman
Cc: Sam Hartman; [email-masked]
Subject: Re: AD review comments on
draft-ietf-cat-kerberos-pk-init-32.txt

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Jan 2006 13:49:50 -0600

> for that non-repudiation and prefect secrecy made the cut.

Yes, that's fine, though to some readers that might imply that PKINIT
provides non-repudation (or PFS).  For AP exchanges at least (the ones
where non-repudiation and PFS would matter most) this is definitely not
the case.

Better to remote that sentence altogether, even if it isn't wrong.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 11:50:48 -0800

It is not about the KDC name, but the realm name or domain name. 

For example, a user from the realm NTDEV.MICROSOFT.COM types in NTDEV as
the short name.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, January 23, 2006 11:45 AM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Hutzelman; Sam Hartman; [email-masked]
Subject: Re: AD review comments on

> different forest, (excuse for the use of MS terminology).

The first issue is why the client would have non-FQDN KDC names in the
first place.

As for where you get the search list from, why, the same way you get it
today, by taking the domainname returned by DHCP and using that as a
one-domain search list until you can figure out what else belongs in the
search list.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Jan 2006 13:45:06 -0600

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 15:12:41 -0500

> For example, a user from the realm NTDEV.MICROSOFT.COM types in NTDEV as

Since the top-level domain NTDEV does not exist, the realm name 'NTDEV' is 
not a valid realm name under the rules set out in RFC4120.  If the 
top-level domain NTDEV did exist, then the likelyhood that the realms which 
legitimately used the names NTDEV and NTDEV.MICROSOFT.COM are actually the 
same realm would seem to be quite small.

It seems like the paragraph under discussion RECOMMENDS that, for 
compatibility with non-standard deployments, CA's adopt a behavior under 
which they would be likely to issue to a KDC a certificate claiming a realm 
name for which that KDC does not legitimately provide service.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Jan 2006 14:54:32 -0600

> For example, a user from the realm NTDEV.MICROSOFT.COM types in NTDEV as

When joining a realm it can't be too much to ask that a user enter a
fully qualified domain/realm name.

In all other circumstances it can't be much to ask that the system have
a DNS search list configured or that users enter fully qualified names
(for names that can't be matched given the search list).

That said, I understand now your implementation note.  I'm not entirely
sure how one would validate that a CA has the authority to vouch for a
non-FQRN, but at least it doesn't seem to do any harm to have them
there -- conforming clients will ignore these.

Now, one issue is: what if there's an NTDEV.FOO.MICROSOFT.COM and an
NTDEV.BAR.MICROSOFT.COM -- which should the user get if they type
"NTDEV"?  If the answer is "don't have multiple sub-domains with the
same prefix label(s)" then that would be an interop note worth
documenting.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 16:16:44 -0500

> crypto systems can not achieve.

... but PKINIT does not provide non-repudiation, because it results in a 
Kerberos ticket, which a KDC can issue whenever it wants.

>> used for?  Are they just algorithms for encrypting the SignedData in the
>> >  EnvelopedData or does this list also include algorithms for

No; there are two encryptions going on here.  The payload is encrypted 
using a temporary symmetric key, and the temporary key is encrypted using 
some public key.  Thus, two algorithms (symmetric and public-key) are in 
use, and it's unclear whether supportedCMSTypes is intended to negotiate 
the symmetric algorithm, the public-key algorithm, or both.

>> the  question of what algorithms exist entirely up to those
>> specifications; it is appropriate for us to specify which algorithms are
>> REQUIRED and to specify  a negotiation mechanism, but except for the
>> enctype definitions, section 3.1.3 seems entirely superfluous to me, and
>> possibly actually harmful -- it  implies that algorithm OID's not listed
>> are not used by PKINIT, and thus that the corresponding algorithms MUST
>> NOT be used.  This specification should > not need to be updated to take
>> advantage of new algorithms defined for CMS.
>
>

This sounds like a substantial semantic change.  As a chair, I would say 
this change requires a WG consensus, or a strong indication that many 
people believed that was the intent all along.  As an individual, I'm not 
sure I see the benefit in making REQUIRED three signature algorithms, two 
public-key encryption algorithms, and three symmetric algorithms, one of 
which is RC2.

> To me, supportedCSMTypes can contain a set of the following:
> des-ede3-cbc, rc2-cbc, id-aes256-CBC. And nothing else for now.

Why not?  What is to prevent an implementation from supporting other 
algorithms?  There's certainly nothing in PKINIT that should present 
problems using other symmetric algorithms defined for CMS, unless we screw 
up and make it too restrictive.

> So let's replace
>        encryption types that are supported by the client in order of
> (decreasing)        preference, and can be used in the
> keyEncryptionAlgorithm field of         the type KeyTransRecipientInfo
> [RFC3852] when encrypting the AS reply key        as described in Section
> 3.2.3.2.

If this is what is intended (that only symmetric algorithms are listed), 
then I have no objection to this change.

>> 4120 successfully defines newer so you should not need to refer to 4121.
>
> The word "newer" is clarified in RFC4121. it is not entirely clear which
> encryption type is "newer" based on rfc4120 alone.

I think it is quite clear:

RFC4120:
   A "newer" enctype is any enctype first officially
   specified concurrently with or subsequent to the issue of this RFC.
   The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not
   "newer" enctypes.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 13:32:50 -0800

Jeffrey Hutzelman wrote:
> ... but PKINIT does not provide non-repudiation, because it results in a Kerberos ticket, which a KDC can issue whenever it wants.
 
Here is what -32 says: 
    The use of asymmetric cryptography in the form of X.509 certificates
   [RFC3280] is popular for facilitating non-repudiation and perfect
   secrecy. 

Does it say anything about what PKINIT does?

Guys if you want to remove the stuff after the "for", the setence become unbalanced and unsteady, don't you think? It is non-normative after all.

Jeff wrote:
> I'm not 
> sure I see the benefit in making REQUIRED three signature algorithms, 

How about changing the "REUQUIRED" to "RECOMMENDED". Or drop the first paragraph completely, if so, we might just drop the whole section as well.

>   The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not

Ok, let's move RFC4121 to be informational (non-normative).
-- Larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Monday, January 23, 2006 1:17 PM
To: Liqiang(Larry) Zhu; Sam Hartman; [email-masked]
Cc: Love Hörnquist Åstrand
Subject: RE: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

On Monday, January 23, 2006 03:49:08 AM -0800 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

>  Sam Hartman wrote:
>> I agree with Martin.  Please avoid non-repudiation as a term.  I 
>> think the security service that matters in the introduction is data 
>> origin authentication.
>

... but PKINIT does not provide non-repudiation, because it results in a Kerberos ticket, which a KDC can issue whenever it wants.

RFC4120:

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 16:49:48 -0500

On Monday, January 23, 2006 01:32:50 PM -0800 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> How about changing the "REUQUIRED" to "RECOMMENDED". Or drop the first
> paragraph completely, if so, we might just drop the whole section as well.

Well, the whole section except for the enctype definitions.  As an 
individual, that would be my preference, but I haven't seen anyone else 
speak up on this yet.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 13:55:29 -0800

Jeffrey Hutzelman wrote:
> Well, the whole section except for the enctype definitions.

Let's move that part into an appendix then, it is for historical reasons only.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Monday, January 23, 2006 1:50 PM
To: Liqiang(Larry) Zhu; Sam Hartman; [email-masked]
Cc: Love Hörnquist Åstrand
Subject: RE: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

> paragraph completely, if so, we might just drop the whole section as well.

Well, the whole section except for the enctype definitions.  As an individual, that would be my preference, but I haven't seen anyone else speak up on this yet.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 17:05:09 -0500

> Let's move that part into an appendix then, it is for historical reasons

Well, I was tempted to suggest dropping it entirely, but that would be a 
substantive change I didn't think was important enough to propose at this 
late ate, and I wasn't sure if there might be implementations out there 
that depended on them.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 15:38:48 -0800

Jeffrey Hutzelman wrote:
> Well, I was tempted to suggest dropping it entirely,

It is fine to me, but again moving to an appendix strikes me as less invasive.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Monday, January 23, 2006 2:05 PM
To: Liqiang(Larry) Zhu; Sam Hartman; [email-masked]
Cc: Love Hörnquist Åstrand
Subject: RE: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

> Let's move that part into an appendix then, it is for historical 

Well, I was tempted to suggest dropping it entirely, but that would be a substantive change I didn't think was important enough to propose at this late ate, and I wasn't sure if there might be implementations out there that depended on them.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Jan 2006 19:06:04 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Monday, January 23, 2006 01:32:50 PM -0800
    Jeffrey> "Liqiang(Larry) Zhu"
    Jeffrey> <[email-masked]> wrote:

    >> How about changing the "REUQUIRED" to "RECOMMENDED". Or drop
    >> the first paragraph completely, if so, we might just drop the
    >> whole section as well.

    Jeffrey> Well, the whole section except for the enctype
    Jeffrey> definitions.  As an individual, that would be my
    Jeffrey> preference, but I haven't seen anyone else speak up on
    Jeffrey> this yet.

I believe the following changes would get this section and the
required algorithms into shape.

1) Add a required contentEncryption algorithm (probably some AES CMS
    varient or 3des CMS varient) to 3.1.1.

2) Remove all of 3.1.2 besides text dealig with enctypes.

3) For each enctype describe which OID in supportedCMSTypes is implied
    by including that OID.

4) If the required algorithm added in 1 has an enctype defined instead
   of just an OID, require that clients send the enctype, send the oid
   or both.  We need to be clear about what is required here.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Jan 2006 19:07:44 -0500

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> Jeffrey Hutzelman wrote:
    >> ... but PKINIT does not provide non-repudiation, because it
    >> results in a Kerberos ticket, which a KDC can issue whenever it
    >> wants.
 
    Liqiang(Larry)> Here is what -32 says: The use of asymmetric
    Liqiang(Larry)> cryptography in the form of X.509 certificates
    Liqiang(Larry)> [RFC3280] is popular for facilitating
    Liqiang(Larry)> non-repudiation and perfect secrecy.

    Liqiang(Larry)> Does it say anything about what PKINIT does?

    Liqiang(Larry)> Guys if you want to remove the stuff after the
    Liqiang(Larry)> "for", the setence become unbalanced and unsteady,
    Liqiang(Larry)> don't you think? It is non-normative after all.

I'm saying that if you replace "non-repudiation" with "data origin
authentication," you will still be making a true statement both about
pkinit and 3280 and you will avoid a nasty political battle in the
PKIX community.

removing the sentence is also OK, but I prefer replacing
non-repudiation with data authentication.

--Sam

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 16:10:01 -0800

Ok, I accept this proposal. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Monday, January 23, 2006 4:08 PM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Hutzelman; [email-masked]; Love Hörnquist Åstrand
Subject: Re: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

 

I'm saying that if you replace "non-repudiation" with "data origin authentication," you will still be making a true statement both about pkinit and 3280 and you will avoid a nasty political battle in the PKIX community.

removing the sentence is also OK, but I prefer replacing non-repudiation with data authentication.

--Sam

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 16:10:37 -0800

Sure, this will be done.

Please tell me what else I need to do before I can send in -33.

-- larry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Monday, January 23, 2006 4:06 PM
To: Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; [email-masked]; Love Hörnquist Åstrand
Subject: Re: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

I believe the following changes would get this section and the required algorithms into shape.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Jan 2006 19:11:48 -0500

>> PKINIT does not define, but does make use of, the following
    >> algorithm identifiers.
    >> 
    >> NEW:
    >> 
    >> In order to promote interoperability, algorithm object
    >> identifiers listed in this section MUST be supported by
    >> conforming implementations.

    Jeffrey> This sounds like a substantial semantic change.  As a
    Jeffrey> chair, I would say this change requires a WG consensus,
    Jeffrey> or a strong indication that many people believed that was
    Jeffrey> the intent all along.  As an individual, I'm not sure I
    Jeffrey> see the benefit in making REQUIRED three signature
    Jeffrey> algorithms, two public-key encryption algorithms, and
    Jeffrey> three symmetric algorithms, one of which is RC2.

I don't think this change is a good idea either as an AD or individual.

    >> des-ede3-cbc, rc2-cbc, id-aes256-CBC. And nothing else for now.

    Jeffrey> Why not?  What is to prevent an implementation from
    Jeffrey> supporting other algorithms?  There's certainly nothing
    Jeffrey> in PKINIT that should present problems using other
    Jeffrey> symmetric algorithms defined for CMS, unless we screw up
    Jeffrey> and make it too restrictive.

I agree with Jeff.

    >> encryption types supported by the client in order of
    >> (decreasing) preference.
    >> 
    >> NEW:
    >> 
    >> [RFC3852] when encrypting the AS reply key as described in
    >> Section 3.2.3.2.

    Jeffrey> If this is what is intended (that only symmetric
    Jeffrey> algorithms are listed), then I have no objection to this
    Jeffrey> change.

I object to this change because keyEncryptionAlgorithm (at least as
far as I can tell) takes a public key algorithm not a symmetric key
algorithm.  I think it is contentEncryptionAlgorithm that takes the
symmetric algorithm.

It seems fairly clear that supportedCMSTypes can take
contentEncryptionAlgorithms; the question in my mind is whether it can
take keyEncryptionAlgorithms.

Or am I horribly confused about CMS?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 19:39:44 -0500

>     varient or 3des CMS varient) to 3.1.1.

Agree.

> 2) Remove all of 3.1.2 besides text dealig with enctypes.

I assume you mean 3.1.3.

> 3) For each enctype describe which OID in supportedCMSTypes is implied

I'm not sure what the issue is here.  For each enctype listed, the document 
does specify which OID is meant, though it is somewhat unclear that these 
enctypes are intended to be treated as equivalent to supportedCMSTypes, and 
very unclear that no further enctypes are supposed to be defined.  I agree 
that if we are eliminating the rest of section 3.1.3, then we need to add 
external references for each OID in the list.

>    or both.  We need to be clear about what is required here.

To address points 2,3,4, I propose replacing the entire text of section
3.1.3 with something like the following:

PKINIT defines the following Kerberos encryption type numbers [RFC3961],
which can be used in the etype field of the AS-REQ [RFC4120] message to
indicate acceptance of the corresponding algorithms for use with
Cryptographic Message Syntax (CMS) [RFC3852].  The presence of each of
these enctypes in the etype field is equivalent to the presence of the
corresponding OID in the supportedCMSTypes field.  Any OID's listed in the
supportedCMSTypes field are to be treated as having higher precedence than
those listed in the etype field.

  Name                           Num OID                        Source
  ============================== === =========================  =========
  id-dsa-with-sha1-CmsOID          9  id-dsa-with-sha1          RFC3279
  md5WithRSAEncryption-CmsOID     10  md5WithRSAEncryption      RFC3279
  sha-1WithRSAEncryption-CmsOID   11  sha-1WithRSAEncryption    RFC3279
  rc2-cbc-EnvOID                  12  rc2-cbc                   RFC3370
  rsaEncryption-EnvOID            13  rsaEncryption             RFC3447
  id-RSAES-OAEP-EnvOID            14  id-RSAES-OAEP             RFC3447
  des-ede3-cbc-EnvOID             15  des-ede3-cbc              RFC3370

Note that these encryption type numbers are used only to indicate support 
for the use of the corresponding algorithms in PKINIT; they do not
correspond to actual Kerberos encryption types [RFC3961] and MUST NOT be
used in the etype field of the Kerberos EncryptedData type.  The practice
of assigning Kerberos encryption type numbers to indicate support for CMS
algorithms is considered deprecated, and new numbers should not be assigned
for this purpose.  Instead, the supportedCMSTypes field should be used to
list OID's naming the supported algorithms.

For maximum interoperability, PKINIT clients wishing to support one or more
of the algorithms listed above MUST list their OID's in supportedCMSTypes,
and SHOULD also list the corrsponding encryption type numbers in the etype
field of the AS-REQ.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 19:44:10 -0500

> Please tell me what else I need to do before I can send in -33.

Tomorrow I will construct a list of issues raised by Gregory's comments and 
by Sam's AD review, and will create issues in RT for each of them.  Note 
that unless I see an indication that we no longer have consensus to 
publish, I will not consider Gregory's comments blocking at this time. 
However, we can/should continue to discuss them, in order to try to reach a 
point where he is satisfied with our responses and/or we have solutions to 
any issues he feels are worth bringing up during IETF Last Call.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 19:45:11 -0500

> Ok, I accept this proposal.

As an individual: Sounds good to me, too.
As a chair: I do wish more people would comment...

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2006 19:52:26 -0500

> Or am I horribly confused about CMS?

You're not confused; I was.  I agree that it's clear that supportedCMSTypes 
is intended to support negotiation of contentEncryptionAlgorithm's (i.e. 
symmetric algorithms).  If it is the intent that it be used only for that, 
then I'm fine with language to that effect.  I do believe that's what Larry 
intended to do; however, on a second reading I agree with Sam that that is 
not what the language Larry proposed actually does.  Instead, that language 
appears to restrict the use of supportedCMSTypes to negotiating only 
keyEncryptionAlgorithm's (i.e. public key), and I don't think that's OK -- 
it is necessary for a client to be able to indicate which symmetric 
algorithms it supports.

Given the discussions related to section 3.1.3, it is becoming more and 
more clear to me that the intent of supportedCMSTypes was to support 
negotiation of both symmetric and public-key encryption algorithms and of 
signature algorithms.  As evidence for this position, I submit that the 
enctypes defined in that section cover all three algorithm types, and that 
the point of supportedCMSTypes was to get out of the business of assigning 
Kerberos enctype numbers to things that weren't really enctypes, and to 
avoid having to wait for such numbers to be assigned before an algorithm 
could be used with PKINIT.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 Jan 2006 17:07:35 -0800

Jeffrey Hutzelman wrote:
> of signature algorithms

Currently it says encryption types, but we can change it to accommodate signature algorithms, but add "there is no significance in the relative order between any two of different types of algorithms: public key encryption algorithms, bulk encryption algorithms, and signature algorithms." sounds good?

-- Larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Monday, January 23, 2006 4:52 PM
To: Sam Hartman
Cc: Liqiang(Larry) Zhu; [email-masked]; Love Hörnquist Åstrand
Subject: Re: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

> Or am I horribly confused about CMS?

You're not confused; I was.  I agree that it's clear that supportedCMSTypes is intended to support negotiation of contentEncryptionAlgorithm's (i.e. 
symmetric algorithms).  If it is the intent that it be used only for that, then I'm fine with language to that effect.  I do believe that's what Larry intended to do; however, on a second reading I agree with Sam that that is not what the language Larry proposed actually does.  Instead, that language appears to restrict the use of supportedCMSTypes to negotiating only keyEncryptionAlgorithm's (i.e. public key), and I don't think that's OK -- it is necessary for a client to be able to indicate which symmetric algorithms it supports.

Given the discussions related to section 3.1.3, it is becoming more and more clear to me that the intent of supportedCMSTypes was to support negotiation of both symmetric and public-key encryption algorithms and of signature algorithms.  As evidence for this position, I submit that the enctypes defined in that section cover all three algorithm types, and that the point of supportedCMSTypes was to get out of the business of assigning Kerberos enctype numbers to things that weren't really enctypes, and to avoid having to wait for such numbers to be assigned before an algorithm could be used with PKINIT.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 24 Jan 2006 02:22:32 -0800

Combining Jeff's text with mine, we have the following:
--------------------------------------------------------------
3.1.3.  Kerberos Encryption Types Defined for CMS Algorithm Identifiers

   PKINIT defines the following Kerberos encryption type numbers
   [RFC3961], which can be used in the etype field of the AS-REQ
   [RFC4120] message to indicate to the KDC the client's acceptance of
   the corresponding algorithms (including public encryption algorithms,
   bulk encryption algorithms, and signature algorithms) for use with
   Cryptographic Message Syntax (CMS) [RFC3852].

   Per [RFC4120], the encryption types in the etype field are in the
   decreasing preference order of the client.  Note that there is no
   significance in the relative order between any two of different types
   of algorithms: public key encryption algorithms, bulk encryption
   algorithms and signature algorithms.

   The presence of each of these encryption types in the etype field is
   equivalent to the presence of the corresponding algorithm Object
   Identifier (OID) in the supportedCMSTypes field as described in
   Section 3.2.1.  And the preference order expressed in the
   supportedCMSTypes field would override the preference order listed in
   the etype field.

    Kerberos Encryption Type Name  Num  Corresponding Algorithm OID
    ============================== === ===============================
    id-dsa-with-sha1-CmsOID        9   id-dsa-with-sha1 [RFC3279]
    md5WithRSAEncryption-CmsOID    10  md5WithRSAEncryption [RFC3279]
    sha-1WithRSAEncryption-CmsOID  11  sha-1WithRSAEncryption [RFC3279]
    rc2-cbc-EnvOID                 12  rc2-cbc [RFC3370]
    rsaEncryption-EnvOID           13  rsaEncryption [RFC3447][RFC3279]
    id-RSAES-OAEP-EnvOID           14  id-RSAES-OAEP [RFC3447][RFC3279]
    des-ede3-cbc-EnvOID            15  des-ede3-cbc [RFC3370]

   The above encryption type numbers are used only to indicate support
   for the use of the corresponding algorithms in PKINIT; they do not
   correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
   be used in the etype field of the Kerberos EncryptedData type
   [RFC4120].  The practice of assigning Kerberos encryption type
   numbers to indicate support for CMS algorithms is considered
   deprecated, and new numbers should not be assigned for this purpose.
   Instead, the supportedCMSTypes field should be used to identify the
   algorithms supported by the client and the preference order of the
   client.

   For maximum interoperability, however, PKINIT clients wishing to
   indicate to the KDC the support for one or more of the algorithms
   listed above SHOULD include the corresponding encryption type numbers
   in the etype field of the AS-REQ. 

-----

This text is more lenient toward legacy implementations/earlier adopters than Jeff's.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Monday, January 23, 2006 4:40 PM
To: Sam Hartman
Cc: Liqiang(Larry) Zhu; [email-masked]; Love Hörnquist Åstrand
Subject: Re: AD review comments on draft-ietf-cat-kerberos-pk-init-32.txt

Agree.

I assume you mean 3.1.3.

> 3) For each enctype describe which OID in supportedCMSTypes is implied

I'm not sure what the issue is here.  For each enctype listed, the document does specify which OID is meant, though it is somewhat unclear that these enctypes are intended to be treated as equivalent to supportedCMSTypes, and very unclear that no further enctypes are supposed to be defined.  I agree that if we are eliminating the rest of section 3.1.3, then we need to add external references for each OID in the list.

PKINIT defines the following Kerberos encryption type numbers [RFC3961], which can be used in the etype field of the AS-REQ [RFC4120] message to indicate acceptance of the corresponding algorithms for use with Cryptographic Message Syntax (CMS) [RFC3852].  The presence of each of these enctypes in the etype field is equivalent to the presence of the corresponding OID in the supportedCMSTypes field.  Any OID's listed in the supportedCMSTypes field are to be treated as having higher precedence than those listed in the etype field.

  Name                           Num OID                        Source

Note that these encryption type numbers are used only to indicate support for the use of the corresponding algorithms in PKINIT; they do not correspond to actual Kerberos encryption types [RFC3961] and MUST NOT be used in the etype field of the Kerberos EncryptedData type.  The practice of assigning Kerberos encryption type numbers to indicate support for CMS algorithms is considered deprecated, and new numbers should not be assigned for this purpose.  Instead, the supportedCMSTypes field should be used to list OID's naming the supported algorithms.

For maximum interoperability, PKINIT clients wishing to support one or more of the algorithms listed above MUST list their OID's in supportedCMSTypes, and SHOULD also list the corrsponding encryption type numbers in the etype field of the AS-REQ.

-- Jeff

---

From: Matt Crawford <[email-masked]>
Date: Tue, 24 Jan 2006 12:03:05 -0600

> As a chair: I do wish more people would comment...

The word non-repudiation has often been toxic to agreement, or even  
to productive discussion, and almost any document is improved by its  
absence.

---

From: Martin Rex <[email-masked]>
Date: Tue, 31 Jan 2006 18:16:51 +0100 (MET)

> non-repudiation with data authentication.

I also stronly prefer "data authentication" over "non-repudation".

But what about the term "perfect secrecy" --
I thought it was called "perfect forward secrecy (PFS)" instead?

-Martin

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 31 Jan 2006 12:23:23 -0800

PFS and PS are used to refer to completely  different beasts.

PS is about zero-knowledge proofs while PFS is about the fact a comprise
of one key does not lead to compromise of earlier keys/sessions.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, January 31, 2006 9:17 AM
To: Sam Hartman
Cc: Liqiang(Larry) Zhu; [email-masked]; [email-masked]; [email-masked]
Subject: Re: AD review comments on

But what about the term "perfect secrecy" -- I thought it was called
"perfect forward secrecy (PFS)" instead?

-Martin