Subject: Please submit pkinit 34

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Feb 2006 17:25:48 -0500

Hi.  I'm aware of no last call comments in the last week or so.
Unless I missed something please submit 34 with the changes you
proposed and let's see what the IESG thinks of the 16th.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Feb 2006 18:35:33 -0500

> proposed and let's see what the IESG thinks of the 16th.

We don't seem to have resolved the question of required key and content 
encryption algorithms.  As I noted in my message of Jan 27, the addition of 
the two paragraphs specifying these requirements is a substantive change 
from the version that passed last call, and requires a WG consensus.  I do 
not believe we have that consensus at this time.

At that time, I also indicated that if we did not choose RSAES-PKCS1-v1_5 
and des-ede3-cbc as the required algorithms, we would have to select 
others.  Since then, it has been pointed out that because these algorithms 
are used only in the public-key encryption AS reply key method and support 
for that method is not REQUIRED, it may not be necessary to specify 
REQUIRED algorithms.

The same commenter suggested that if we do specify such requirements, we 
should be clear that doing so is not an indication that the public-key 
encryption AS reply key method itself is required.  I believe this could be 
accomplished by adding the following sentence to each of the two paragraphs 
quoted in my earlier message:

   "Support for this algorithm is REQUIRED only if the AS reply key
    delivery method described in section 3.2.3.2 is supported".

Note I offer this only as one possible way to resolve Chaskiel's concern; 
other approaches are possible, if someone wants to suggest one.

As I stated before, I believe that a WG consensus is required to specify 
mandatory algorithms in these categories, where the version that passed 
last call did not.  Lacking such a consensus, the only thing we will be 
able to do is remove the two paragraphs in question entirely.

However we choose to resolve this issue, it can likely be fixed in an 
RFC-Editor note, without the need for another new verison of the document 
(unless there are sufficient changes resulting from IESG comments that a 
new version is warranted).  However, I would prefer to have our ultimate 
decision reflected in the document the IESG reviews.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Feb 2006 20:16:16 -0500

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

    Jeffrey> On Monday, February 06, 2006 05:25:48 PM -0500 Sam
    Jeffrey> Hartman

    >> proposed and let's see what the IESG thinks of the 16th.

    Jeffrey> We don't seem to have resolved the question of required
    Jeffrey> key and content encryption algorithms.  As I noted in my
    Jeffrey> message of Jan 27, the addition of the two paragraphs
    Jeffrey> specifying these requirements is a substantive change
    Jeffrey> from the version that passed last call, and requires a WG
    Jeffrey> consensus.  I do not believe we have that consensus at
    Jeffrey> this time.

My error for not noticing this was still open.

    Jeffrey> At that time, I also indicated that if we did not choose
    Jeffrey> RSAES-PKCS1-v1_5 and des-ede3-cbc as the required
    Jeffrey> algorithms, we would have to select others.  Since then,
    Jeffrey> it has been pointed out that because these algorithms are
    Jeffrey> used only in the public-key encryption AS reply key
    Jeffrey> method and support for that method is not REQUIRED, it
    Jeffrey> may not be necessary to specify REQUIRED algorithms.

For each option you need required algorithms such that if if the
option is implemented you can get interoperability.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Feb 2006 20:41:42 -0500

Larry is apparently having some trouble getting messages through to the 
list (or to my own mailbox).  He asked me to forward the following:

-----Original Message-----
From: Liqiang(Larry) Zhu
Sent: Monday, February 06, 2006 5:01 PM
To: 'Jeffrey Hutzelman'; Sam Hartman
Cc: [email-masked]
Subject: RE: Please submit pkinit 34

I propose to move these into a separate sub-section in section 3.1, 
"Recommended Algorithms". And in this new sub section the public key 
encryption is a "SHOULD" with these additional paragraphs.

Aren't there folks saying it can go any direction, and it does not really 
matter as far as this point is concerned.

-- larry

---

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Feb 2006 22:17:29 -0500

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

    Jeffrey> Larry is apparently having some trouble getting messages
    Jeffrey> through to the list (or to my own mailbox).  He asked me
    Jeffrey> to forward the following:

    Jeffrey> -----Original Message----- From: Liqiang(Larry) Zhu Sent:
    Jeffrey> Monday, February 06, 2006 5:01 PM To: 'Jeffrey
    Jeffrey> Hutzelman'; Sam Hartman Cc: [email-masked] Subject:
    Jeffrey> RE: Please submit pkinit 34

    Jeffrey> I propose to move these into a separate sub-section in
    Jeffrey> section 3.1, "Recommended Algorithms". And in this new
    Jeffrey> sub section the public key encryption is a "SHOULD" with
    Jeffrey> these additional paragraphs.

So long as it is clear that if you support public key encryption reply
at all, you must support the specified content encryption algorithms.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 6 Feb 2006 17:00:39 -0800

Aren't there folks saying it can go any direction, and it does not
really matter as far as this point is concerned.

-- larry 

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Monday, February 06, 2006 3:36 PM
To: Sam Hartman; Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: Please submit pkinit 34

We don't seem to have resolved the question of required key and content
encryption algorithms.  As I noted in my message of Jan 27, the addition
of the two paragraphs specifying these requirements is a substantive
change from the version that passed last call, and requires a WG
consensus.  I do not believe we have that consensus at this time.

At that time, I also indicated that if we did not choose
RSAES-PKCS1-v1_5 and des-ede3-cbc as the required algorithms, we would
have to select others.  Since then, it has been pointed out that because
these algorithms are used only in the public-key encryption AS reply key
method and support for that method is not REQUIRED, it may not be
necessary to specify REQUIRED algorithms.

The same commenter suggested that if we do specify such requirements, we
should be clear that doing so is not an indication that the public-key
encryption AS reply key method itself is required.  I believe this could
be accomplished by adding the following sentence to each of the two
paragraphs quoted in my earlier message:

Note I offer this only as one possible way to resolve Chaskiel's
concern; other approaches are possible, if someone wants to suggest one.

However we choose to resolve this issue, it can likely be fixed in an 
RFC-Editor note, without the need for another new verison of the
document 
(unless there are sufficient changes resulting from IESG comments that a

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 7 Feb 2006 00:24:53 -0800

I agree. Here is the proposed new section 3.1.2. please check if this
is clear.

3.1.  Definitions, Requirements, and Constants

3.1.1.  Required Algorithms

   All PKINIT implementations MUST support the following algorithms:

   o  AS reply key enctype(s): aes128-cts-hmac-sha1-96 and aes256-cts-
      hmac-sha1-96 [RFC3962].

   o  Signature algorithm(s): sha-1WithRSAEncryption [RFC3370].

   o  AS reply key delivery method(s): the Diffie-Hellman key delivery
      method as described in Section 3.2.3.1.

   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].

3.1.2.  Recommended Algorithms

   All PKINIT implementations SHOULD support the following algorithms:

   o  AS reply key delivery method(s): the public key encryption key
      delivery method as described in Section 3.2.3.2.

   For implementations that support the public key encryption key
   delivery method, the following algorithms MUST be supported:

   a) Key transport algorithm(s) identified in the
      keyEncryptionAlgorithm field of the type KeyTransRecipientInfo
      [RFC3852] for encrypting the temporary key in the encryptedKey
      field [RFC3852] with a public key, as described in
      Section 3.2.3.2: rsaEncryption (this is the RSAES-PKCS1-v1_5
      encryption scheme) [RFC3370] [RFC3447].

   b) Content encryption algorithm(s) identified in the
      contentEncryptionAlgorithm field of the type EncryptedContentInfo
      [RFC3852] for encrypting the AS reply key with the temporary key
      contained in the encryptedKey field of the type
      KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2:
      des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370]. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Monday, February 06, 2006 7:17 PM
To: Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; [email-masked]
Subject: Re: Please submit pkinit 34

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 07 Feb 2006 04:02:11 -0500

This looks fine to me.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Feb 2006 10:56:27 -0500

This proposal sounds reasonable to me as an individual and addresses
the constraints I raised as an AD.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Feb 2006 15:28:47 -0500

>  I agree. Here is the proposed new section 3.1.2. please check if this

Looks good to me.

> I propose to add a new error code:
>
> KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81

This, too, and Tom says the number appears to be available.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Feb 2006 17:26:40 -0500

On Tuesday, February 07, 2006 11:13:50 PM +0100 Martin Rex 
<[email-masked]> wrote:

> I also like to see the term "non-repudiation" be replaced
> with "data-origin authentication" since there "non-repudiation".
> "non-repudiation" doesn't seem to meet rough consensus
> and there has been no technical convincing argument why
> "data-origin authentication" would not work.

That change was made in -33.

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Feb 2006 23:13:50 +0100 (MET)

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 8 Feb 2006 00:20:15 +0100 (MET)

> That change was made in -33.
 
Blush.   Sorry, I missed this.

With respect to other allegedly normative things in rfc3280,
I've recently stumbled across two other things:

 - VeriSign seems to be still operating a rootCA that uses an
   X.509v1 cert to sign/issue SSL Server certificates, although
   rfc2459 and its successor rfc3280 explicitly require CAs
   to contain "Basic Constraints cA=TRUE" extension, which
   rules out a X.509v1 certificate for such a CA.
   (example: https://register.hp.com)

 - There seems to be a tradition in abusing the T61String
   containers for what are really ISO-Latin1 strings by some CAs
   and by some PKI software.  rfc2459 and rfc3280 require that
   CAs and software must use UTF8String to encode ISO-Latin1
   chars and stop abusing the T61String tag.
   I still see that abuse today (we got a complaint that our (oem)
   software visualizes T61Strings with their correct/original meaning,
   which differs from what popular browsers visualize.

rfc-2459 was put on the standards track seven years ago.
Some of the "Requirements" in PKI-related standards appear overly ambitious...

I also remember the discussion about "subject key identifiers",
how they were required and that they were the prefered method to
identify certificates.

There seems to be a serious misconception with the people who designed
them and as a result with those who started using them.
Subject Key Identifiers are only good to identify (public) keys, they are
a bad choice to identify certificates.  And they're are added
complexity with zero benefit, i.e. a real waste.

the algorithm how subject key identifiers are (and should be) generated
is based only on the public key -- and for this purpose, a standardized
fingerprinting of the public key would have been totally sufficient
(and would have covered all existing certs as well).

Situations where there is more than one certificate with the
same subject key identifier:
- when cross-certificates are being used
- when certificates are re-issued (with the same key but an extended lifetime)

Real problems arise when path validation fails and some protocol
designers think that communicating the subject key identifier of
the offending certificate will non-ambiguously identify the
certificate (which can easily fail in above situations).

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Feb 2006 18:37:09 -0500

> Some of the "Requirements" in PKI-related standards appear overly

It's unfortunate that there are still non-compliant implementations out 
there, but there is little we can do about it.  We can define secure, 
interoperable protocols; we cannot force anyone to use them correctly.  In 
any case, problems with PKIX or PKIX implementations are best left to other 
working groups.

> (and would have covered all existing certs as well).

In practice, that's exactly what is used.  The subject keyid's in 
certificates I've seen are a SHA-1 hash of the encoded public key.

> certificate (which can easily fail in above situations).

Which is why PKINIT requires the use of an issuerAndSerialNumber, not a 
subject keyid, for TD-INVALID-CERTIFICATES.  The discussion was long and 
messy, but I do believe we've gotten this right.

-- Jeff