WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.

Folks,

I'm back from a 3 week vacation and catching up on e-mail.  It 
appears that there have been no substantive comments on the list re 
this document, which was revised before the Dublin IETF meeting, and 
briefed there by Carl Wallace. So, I am initiating WGLC effective 
today, and continuing through 10/15.

Thanks,

Steve

WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt

I have been told that the IEEE 801.1 AR folks are hoping to refer to 
cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their work, so it 
behooves us to move ahead as soon as possible.  It also appears that 
discussion has settled down on this draft, so I am initiating WGLC on 
it as well, effective today, and continuing until 10/15.

Thanks,

Steve

draft-turner-caclearanceconstraints-01.txt

RE: draft-turner-caclearanceconstraints-01.txt

RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5

We could put something like the following in the security considerations
section:

Cryptographic algorithms will be broken or weakened over time.  Implementers
and users need to check that the cryptographic algorithms listed in this
document continue to provide the expected level of security.  For example,
some consider MD2 and MD5 weak cryptographic algorithms due to collisions
[RC95] and [YU05], repsectively.

Informative references (found this in old RFCs and on web):
[RC95] Rogier, N. and P. Chauvaud, "The compression function  of MD2 is not
collision free," Presented at Selected Areas in Cryptography '95, May 1995.
[XY05] Wang, X., and H. Yu, "How to Break MD2 and Other Hash Functions",
EUROCRYPT 2005, LNCS 3494, pp. 19–35, 2005. 

spt

>-----Original Message-----
>From: owner-ietf-pkix <at> mail.imc.org 
>[mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Russ Housley
>Sent: Tuesday, September 30, 2008 5:23 PM
>To: Jim Schaad; 'Alfred HÎnes'; ietf-pkix <at> imc.org
>Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
>
>
>There was a long discussion a few years ago, and the PKIX WG 
>decided that the various applications that make use of 
>certificate should select the mandatory to implement 
>algorithms.  In this way, the algorithms in the protocol and 
>in the certificates can be aligned.
>
>Russ
>
>At 03:17 PM 9/30/2008, Jim Schaad wrote:
>>Alfred,
>>
>>That is an interesting question.  I don't believe that there 
>have ever 
>>been any required algorithms for PKIX certificates as defined by the 
>>PKIX working group.  You have documents such as the S/MIME 
>certificates 
>>draft which says you need to use these algorithms for S/MIME 
>type certificates instead.
>>
>>I think that it would make sense to put a section into the security 
>>considerations that make statements about what we consider to be the
>>suitability of other groups adopting these algorithms.   I 
>don't however
>>believe we can actually call these algorithms depreciated however.
>>
>>Jim
>>
>>
>> > -----Original Message-----
>> > From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf- 
>> > pkix <at> mail.imc.org] On Behalf Of Alfred HÎnes
>> > Sent: Sunday, September 28, 2008 7:08 PM
>> > To: ietf-pkix <at> imc.org
>> > Subject: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
>> >
>> >
>> > Folks,
>> > the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains 
>> > unqualified ASN.1 definitions for the digest algorithms MD-2 and 
>> > MD-5, as well as for  RSA with MD-2 and MD-5.
>> >
>> > Other WGs already have deprecated MD-2 and/or MD-5 and/or 
>are in the 
>> > process of deprecating these older hash functions (generally 
>> > believed to be insecure today), for use in the protocols 
>they maintain.
>> >
>> > So the question arises what to do with these old algorithms in the 
>> > context of PKIX in general, and in particular in the above draft.
>> >
>> > I see four possible options:
>> >
>> >   A)  leave the draft unchanged
>> >
>> >   B)  leave the related ASN.1 definitions intact,
>> >       but add ASN.1 comments  ' -- DEPRECATED'
>> >
>> >   C)  keep the related ASN.1 definitions in the document
>> >       for the purpose of documentation and historical record,
>> >       but comment them out and add the above note
>> >
>> >   D)  remove he related ASN.1 from the new/upated ASN.1
>> >       modules in Appendix A.2 and Appendix A.4 of the draft
>> >
>> > This question should be decided upon (almost independently):
>> >
>> >     (1)  for  MD-2  and  RSA with MD-2  ... choices (1A), ... (1D) 
>> > and
>> >     (2)  for  MD-5  and  RSA with MD-5  ... choices (2A), ... (2D)
>> >
>> > Any opinions?
>> >
>> > Please indicate support for
>> > - one of:            (1A) / (1B) / (1C) / (1D)
>> > - and one of:        (2A) / (2B) / (2C) / (2D)
>> >
>> >
>> > Kind regards,
>> >   Alfred.
>> >
>> >
>> > P.S.:  My personal preference is  (1C) + (2B) .
>> > --
>> >
>> > 
>+------------------------+--------------------------------------------+
>> > | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., 
>Dipl.-Phys.  |
>> > | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: 
>-18         |
>> > | D-71254  Ditzingen     |  E-Mail:  ah <at> TR-Sys.de          
>           |
>> > 
>+------------------------+--------------------------------------------+
>>
>>
>

RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5

At 5:29 PM -0400 10/1/08, Turner, Sean P. wrote:
>We could put something like the following in the security considerations
>section:
>
>Cryptographic algorithms will be broken or weakened over time.  Implementers
>and users need to check that the cryptographic algorithms listed in this
>document continue to provide the expected level of security.  For example,
>some consider MD2 and MD5 weak cryptographic algorithms due to collisions
>[RC95] and [YU05], repsectively.
>
>Informative references (found this in old RFCs and on web):
>[RC95] Rogier, N. and P. Chauvaud, "The compression function  of MD2 is not
>collision free," Presented at Selected Areas in Cryptography '95, May 1995.
>[XY05] Wang, X., and H. Yu, "How to Break MD2 and Other Hash Functions",
>EUROCRYPT 2005, LNCS 3494, pp. 19-35, 2005.

I do not agree with putting this text into this document, as compared to well, um, every single document
coming out of the Security Area. It's both obvious and insufficient advice. Without context, it will seem
that the advice is more important here than in other Security Area documents.

--Paul Hoffman, Director
--VPN Consortium

Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt

I have read this document, and I believe that it is ready for the 
PKIX WG to send to the IESG.

I can confirm that a reference for IEEE 802.1AR is desired.

Russ

At 04:16 PM 10/1/2008, Stephen Kent wrote:

>I have been told that the IEEE 801.1 AR folks are hoping to refer to 
>cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their work, so 
>it behooves us to move ahead as soon as possible.  It also appears 
>that discussion has settled down on this draft, so I am initiating 
>WGLC on it as well, effective today, and continuing until 10/15.
>
>Thanks,
>
>Steve

RE: Last Call Comments on ecc-subpubkeyinf-08

Jim,

Thanks for taking the time to review the draft.  Responses are inline.

spt 

>-----Original Message-----
>  1.  Is ECParameters considered to be extensible?  The 
>following text says yes, but the ASN.1 does not make this explicit.
>
>   The addition of any new choices in ECParameters ought to be 
>   coordinated with ANSI X9.

I'll change it to:

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve}),
  implicitCurve   NULL,
  -- specifiedCurve  SpecifiedECDomain
  ... -- Extensible
}
  -- specifiedCurve MUST NOT be used in PKIX.
  -- Details for SpecifiedECDomain can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ASNI X.9.

>2.  The text in section 2.1 is a bit odd.  It says that ECDH 
>is defined as... and then what follows is the definition of an 
>ECDH specific Public Key, not the key agreement algorithm.  
>This text should be clarified about what is being identified 
>at this point.

How about:

o pk-ecDH indicates that the algorithm that can be used with the subject
public key is restricted to the Elliptic Curve Diffie-Hellman algorithm.
See Section 2.1.2.  This choice MAY be supported.

o pk-ecMQV indicates that the algorithm that can be used with the subject
public key is restricted to the Elliptic Curve Menezes-Qu-Vanstone key
agreement algorithm.  See Section 2.1.2.    This choice MAY be supported.

>3.  Section 3 is not consistent in nomenclature.  It specifies 
>id-ecPublicKey, but then specifies ecDH not id-ecDH.  This 
>usage needs to be consistent to either the object or the OID.

See #4

>4.  Section 3 - it would be nice if the last paragraph was 
>formatted the same as the preceding paragraphs so that the 
>bits set are simple to understand.

How about:

If the keyUsage extension is present in a certificate that indicates id-ecDH
or id-ecMQV in subjectPublicKeyInfo, then the following MUST be present

  keyAgreement;

the following MUST NOT be present:

  digitalSignature;
  nonRepudiation;
  keyTransport;
  keyCertSign; and,
  and cRLSign

the following MAY be present:

 encipherOnly; or,
 decipherOnly.

>5.  Is there a reason why a pk-ecDSA public key is not defined 
>that can only be used with for the purposes of signing?  I 
>realize this is somewhat duplicated by the signing only bit, 
>however there might be a new ECC signing algorithm that comes 
>into existence in the future.

The design team felt that ECDSA was already in the wild and implemented with
id-ecPublicKey so we didn't want to disturb the installed base.  The design
team felt constraints (if needed) would only need to be applied to ECC key
agreement algorithms.  If the new algorithm can't be represented by
id-ecPublicKey the same way ECDSA, ECDH, and ECMQV can all be represented by
id-ecPublicKey, then a new OID will need to be assigned for the future
signature algorithm.  

RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5

At 3:35 PM -0700 10/1/08, Paul Hoffman wrote:
>At 5:29 PM -0400 10/1/08, Turner, Sean P. wrote:
>>We could put something like the following in the security considerations
>>section:
>>
>>Cryptographic algorithms will be broken or weakened over time.  Implementers
>>and users need to check that the cryptographic algorithms listed in this
>>document continue to provide the expected level of security.  For example,
>>some consider MD2 and MD5 weak cryptographic algorithms due to collisions
>>[RC95] and [YU05], repsectively.
>>
>>Informative references (found this in old RFCs and on web):
>>[RC95] Rogier, N. and P. Chauvaud, "The compression function  of MD2 is not
>>collision free," Presented at Selected Areas in Cryptography '95, May 1995.
>>[XY05] Wang, X., and H. Yu, "How to Break MD2 and Other Hash Functions",
>>EUROCRYPT 2005, LNCS 3494, pp. 19-35, 2005.
>
>I do not agree with putting this text into this document, as 
>compared to well, um, every single document coming out of the 
>Security Area. It's both obvious and insufficient advice. Without 
>context, it will seem that the advice is more important here than in 
>other Security Area documents.
>
>--Paul Hoffman, Director
>--VPN Consortium

Paul,

I agree that the wording might be improved, but I do think that PKIX 
is a special case vs. most of the crypto-related RFCs in the security 
area.  The reason is that we don't define specific algorithm suites 
as do IPsec, TLS, SMIME, SSH, etc. Since we don't specify default or 
preferred algorithms, our standards that do mention specific 
algorithms are more susceptible to misinterpretation by readers 
unfamiliar with that aspect of PKIX standards.

I support Sean's efforts to try to avoid such confusion, in response 
to Jim's comments. I hope Sean can tweak the words a bit to make this 
more acceptable. I do think the MD2 MD5 references may be helpful as 
well.

Steve

RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5

At 12:35 PM -0400 10/2/08, Stephen Kent wrote:
>I agree that the wording might be improved, but I do think that PKIX is a special case vs. most of the
crypto-related RFCs in the security area.  The reason is that we don't define specific algorithm suites as
do IPsec, TLS, SMIME, SSH, etc. Since we don't specify default or preferred algorithms, our standards
that do mention specific algorithms are more susceptible to misinterpretation by readers unfamiliar
with that aspect of PKIX standards.

We have not seen that someone reading RFC 3279 would tend to think that the IETF is suggesting that all of its
algorithms are equally strong or useful. In fact, we have seen the opposite. I do not think that this
document will be any different.

Or, are you proposing that we update RFCs 3279, 4055, and 4491 to have wording similar to what Sean proposed?

--Paul Hoffman, Director
--VPN Consortium