Subject: [Sam Hartman] Last calling pkinit 33

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Jan 2006 17:35:29 -0500

Subject: Last calling pkinit 33
From: Sam Hartman <[email-masked]>
To: "Liqiang(Larry) Zhu" <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 24 Jan 2006 11:47:00 -0500

Hi.  I'm going to last call -33 as soon as it is available.  I believ
it addresses all my AD review comments with the exception of the
question about rsaEncryption.  It will be last called along with OCSP
for pkinit.

I noticed a change made to the diagram in the introduction.  Can Larry
or anyone who can look at the diagram please confirm it still looks
OK?

I'm also uncomfortable with the following change:

+   o  Algorithms identified in the contentEncryptionAlgorithm field of
+      the type EncryptedContentInfo [RFC3852] for encrypting the
+      temporary key in the encryptedKey field of the type
+      KeyTransRecipientInfo [RFC3852] with a public key, as described in
+      Section 3.2.3.2: rsaEncryption [RFC3447] [RFC3279].

As far as I can tell, rsaEncryption identifies a type of public key
and is neither a bulk nor public key encryption algorithm.  I don't
think it belongs anywhere in pkinit.

I will not block last call on this issue but we need to come to
closure before approval.

--Sam

---

From: Chaskiel M Grundman <[email-masked]>
Date: Wed, 25 Jan 2006 00:35:48 -0500

> think it belongs anywhere in pkinit.

in RFC3279, rsaEncryption identifies a type of public key
in RFC3370 [CMSALGS], rsaEncryption identifies a public key encryption 
algorithm.

it appears to me that all the references to RFC3279 in sections 3.1.1 and 
3.1.3 of pkinit are incorrect, as rfc3279's discuses only the labeling of 
keys and signatures in certificates:

   "This specification defines the contents of the signatureAlgorithm,
   signatureValue, signature, and subjectPublicKeyInfo fields within
   Internet X.509 certificates and CRLs."

>    id-RSAES-OAEP-EnvOID           14  id-RSAES-OAEP [RFC3447][RFC3279]
This reference should be changed to RFC3560 "Use of the RSAES-OAEP Key 
Transport Algorithm in the Cryptographic Message Syntax. The other 3279 
references in 3.1.1 and 3.1.3 should be changed to RFC3370 [CMSALGS]

The other references to 3279 are better, since they are actually about 
labeling transported public key objects, not algorithms, but the question 
"is 3279 an appropriate reference for describing the transport of public 
keys outside an X.509 certificate" should probably be asked.

Lastly, assuming the current section 3.1.1 is retained (a relatively large 
list of required alorithms), then the working group should probably 
consider whether RSAES-PKCS1-v1_5. (rsaEncryption) or RSAES-OAEP 
(id-RSAES-OAEP) should be the required rsa algorithm,

---

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

I agree with Chaskiel's his comments below.

I submit that I was confused by 3279.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Tuesday, January 24, 2006 9:36 PM
To: [email-masked]
Subject: Re: [Sam Hartman] Last calling pkinit 33

> think it belongs anywhere in pkinit.

in RFC3279, rsaEncryption identifies a type of public key in RFC3370
[CMSALGS], rsaEncryption identifies a public key encryption algorithm.

it appears to me that all the references to RFC3279 in sections 3.1.1
and
3.1.3 of pkinit are incorrect, as rfc3279's discuses only the labeling
of keys and signatures in certificates:

The other references to 3279 are better, since they are actually about
labeling transported public key objects, not algorithms, but the
question "is 3279 an appropriate reference for describing the transport
of public keys outside an X.509 certificate" should probably be asked.

Lastly, assuming the current section 3.1.1 is retained (a relatively
large list of required alorithms), then the working group should
probably consider whether RSAES-PKCS1-v1_5. (rsaEncryption) or
RSAES-OAEP
(id-RSAES-OAEP) should be the required rsa algorithm,

---

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

Chaskiel, thanks for your excellent comments. I support all your updates
to the references in section 3.1.1 and 3.1.3. 

Chaskiel wrote:
> but the question "is 3279 an appropriate reference for describing the
transport of public keys outside an X.509 certificate" should probably
be asked.

RFC3852 CMS imports structures from RFC3280, therefore it is reasonable
to say, fill out or encode these structures according to RFC3279,
correct?

I just checked the rest of RFC3279 references outside of 3.1.1 and
3.1.3, they appear to be ok.

probably consider 
> whether RSAES-PKCS1-v1_5. (rsaEncryption) or RSAES-OAEP

RSAES-PKCS1-v1_5 is the only one listed in RFC3370, and this is used in
the deployments. RSAES-PKCS1-v1_5 is the only one that is listed as
required in -33.

Based on RFC3370, I would suggest the following changes to -33

s/public key encryption/key transport/g
s/bulk encryption/content encryption/g

Thus we would use consistent terminology with regard to RFC3370. Any
comments?

-- Larry

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Jan 2006 11:53:18 -0500

So, I tend to agree the major open issue is which of PKCS1 1.5 or OAEP
is mandatory to implement.

I suspect Larry is going to tell us that we need to require PKCS1 1.5
for interoperability reasons.  That seems to be the standard across
the industry for most PKI applications.

So, do we require/recommend/optional OAEP?

Finally, I'd ask that the description of the rsaEncryption OID
reference either CMS or the PKCS1 2.1 spec but not 3279 and explicitly
say that it means PKCS1 v1_5 encryption.

I'd like to hold off for a day or so on submitting a new draft until
this gets settled out.  I don't see that this issue blocks a last
call.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Jan 2006 18:05:10 -0500

Folks, I've seen no comments on what our mandatory to implement
algorithms are.

It would be unfortunate if we failed to publish pkinit because we were
unable to decide two bits of information.

---

From: Brian Tung <[email-masked]>
Date: Fri, 27 Jan 2006 15:26:26 -0800

> So, do we require/recommend/optional OAEP?

I vote for "recommend."

> say that it means PKCS1 v1_5 encryption.

Are you asking if it should reference CMS or if it should ref PKCS1 2.1?

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 27 Jan 2006 19:43:17 -0500

> this gets settled out.  I don't see that this issue blocks a last

Larry has proposed the following text for PKINIT-34:

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

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

In my opinion, this is substantially the same as what is in PKINIT-33, 
currently in IETF Last Call.  The references have been cleaned up, and the 
explicit mention of PKCS1.5 is there; also, a typo was corrected in the 
first paragraph.

>From my viewpoint as chair, the difficulty arises from the fact that 
neither these two paragraphs nor anything like them appeared in the version 
that passed last call in this WG.  In particular, we previously did not 
specify _any_ mandatory-to-implement key or content encryption algorithms.

So, I'd like to ask for comments from the WG on whether or not to accept 
the algorithms mentioned in the above two paragraphs (RSAES-PKCS1-v1_5 and 
des-ede3-cbc) as the REQUIRED algorithms.  Note that if the answer turns 
out to be no, we will need to select some other algorithm.  Either way, I 
want to have this resolved by the time the IETF Last Call ends on Feb 8.

-- Jeff

---

From: Chaskiel M Grundman <[email-masked]>
Date: Fri, 27 Jan 2006 21:02:05 -0500

--On Friday, January 27, 2006 07:43:17 PM -0500 Jeffrey Hutzelman 
<[email-masked]> wrote:

> neither these two paragraphs nor anything like them appeared in the 
version that
> passed last call in this WG.  In particular, we previously did not 
specify _any_
> mandatory-to-implement key or content encryption algorithms.
The version that passed last call specifies that the mandatory to implement 
AS reply key delivery method is DH, not RSA. Therefore, I don't think we 
need to specify key or content encryption algorithms.

I do not object to the proposed additions, but only if it is made clear 
that we aren't (implicitly) requiring support of the Public Key Encryption 
AS reply key method.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Jan 2006 21:21:35 -0500

The one concern I see with this approach is that it may make FIPS
certification challenging because 3DES is weaker than AES128, which is
the weakest reply key algorithm we mandate.

Although Russ pointed out to me that FIPS certification for Kerberos
may already be challenging because CTS is not an approved mode of
operation.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 28 Jan 2006 00:25:07 -0500

> the weakest reply key algorithm we mandate.

Note that this is three-key 3DES.  Also, I thought it was still possible to 
get certification with 3DES alone, so I wouldn't think there would be a 
problem with a combination of 3DES and a stronger algorithm.  But federal 
crypto standards is not exactly my area of expertise...

> may already be challenging because CTS is not an approved mode of

Fortunately, we have algorithm agility, so if that proves to be a 
significant burden, someone can always define an AES enctype which uses an 
approved mode.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 27 Jan 2006 22:32:19 -0800

Excellent points. If the public key encryption method is not even
required, then the use of 3DES won't be an issue w.r.t. FIPS
certification. 

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Friday, January 27, 2006 6:02 PM
To: [email-masked]
Subject: Re: Mandatory to implements

version that
specify _any_
> mandatory-to-implement key or content encryption algorithms.
The version that passed last call specifies that the mandatory to
implement AS reply key delivery method is DH, not RSA. Therefore, I
don't think we need to specify key or content encryption algorithms.

I do not object to the proposed additions, but only if it is made clear
that we aren't (implicitly) requiring support of the Public Key
Encryption AS reply key method.

---

From: Ken Raeburn <[email-masked]>
Date: Sat, 28 Jan 2006 02:22:03 -0500

> may already be challenging because CTS is not an approved mode of

Which specs would this be under?  I believe it can be argued pretty  
effectively that the use of CTS is compliant with both FIPS 81 and  
SP800-38A, for example.  Both specs allow some latitude in how the  
application deals with a partial final block, and that's mostly what  
CTS is about.  Has anyone actually tried to get certification for  
uses of CTS?  (I'm tempted to write up an argument for it, just so I  
don't keep wasting time re-creating it in my head every time this  
issue comes up, but I don't know anything about the certification  
process issues that might need to be addressed.)

My understanding was also that the planned revision of SP800-38A is  
likely to describe a form of CTS, but I haven't been paying close  
attention recently.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Sun, 29 Jan 2006 13:12:12 -0500

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

    Liqiang(Larry)> Excellent points. If the public key encryption
    Liqiang(Larry)> method is not even required, then the use of 3DES
    Liqiang(Larry)> won't be an issue w.r.t. FIPS certification.

Yep, that's true.