Re: [pkix] I-D Action:draft-ietf-pkix-new-asn1-07.txt

[Stefan Santesson <[e-mail]>]

I made an update on my position, but there seems to be quite a delay in mail
delivery currently :)

/Stefan


On 09-09-01 2:38 AM, "Paul Hoffman" <[e-mail]> wrote:

> At 9:34 PM +0200 8/31/09, Stefan Santesson wrote:
>> I'm OK with the change.
>> 
> 
> At 7:51 PM -0400 8/31/09, Stephen Kent wrote:
>> I have no objections to making these changes.
>> 
> 
> Just to be clear: both of you are fine with us changing the modules *for RFC
> 3281* to be different than what is in that RFC?
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JGIn4X085254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 09:18:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JGInt8085253; Wed, 19 Aug 2009 09:18:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JGIeuZ085245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 19 Aug 2009 09:18:49 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-040.bbn.com ([128.89.89.40]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Mdnrv-0004hm-CI; Wed, 19 Aug 2009 12:18:35 -0400
Mime-Version: 1.0
Message-Id: <p0624080ac6b1d53f0269@[128.89.89.40]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 19 Aug 2009 12:15:19 -0400
To: Sean Turner <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Cc: Santosh Chokhani <[e-mail]>, Stefan Santesson <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A
>...
>
>On a new topic: Another concern I have is that there's a DoS attack 
>when the attacker sends a really big bogus signture and the client 
>has to spend time figuring this out.  We had a long discussion about 
>this on the SMIME list.  We added a security consideration in 
>draft-ietf-smime-3851bis as follows:
>
>  Receiving agents that validate signatures and sending agents that
>  encrypt messages, need to be cautious of cryptographic processing
>  usage when validating signatures and encrypting messages using keys
>  larger than those mandated in this specification.  An attacker could
>  send certificates with keys which would result in excessive
>  cryptographic processing, for example keys larger than those mandated
>  in this specification, which could swamp the processing element.
>  Agents which use such keys without first validating the certificate
>  to a trust anchor are advised to have some sort of cryptographic
>  resource management system to prevent such attacks.

I agree that analogous text would be appropriate here.

>>...
>
>There are 2 tables in RFC 5480.  The 1st lists the possibilities for 
>ECDSA but the 2nd (on page 10) provides some RECOMMENDED key sizes, 
>hashes, and curves for a given # of bits of security.  What I was 
>saying is that if we use that table, then we could infer everything. 
>But, the group will need to agree to that.

I like referring to such tables as a way to keep things simple, and 
increase the likelihood of interoperability.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JFAGox080138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 08:10:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JFAG1Y080137; Wed, 19 Aug 2009 08:10:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JFA8Iv080127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 19 Aug 2009 08:10:13 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 6d51c8a4.2352397232.293312.00-008.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Wed, 19 Aug 2009 09:10:14 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Wed, 19 Aug 2009 11:10:07 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
thread-index: AcogzNiCoRAynR2zSeCE0PVkLkBd0wABlg7Q
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Sean Turner" <[e-mail]>, "Manger, James H" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am ok with Sean's suggestion that I repeat below:=20

PreferredSignatureAlgorithm ::=3D SEQUENCE {
     sigIdentifier   AlgorithmIdentifier,
     certIdentifier  AlgorithmIdentifier OPTIONAL }
=20
sigIdentifier is the identifier the client would like to see in the
signature.  certIdentifier is the identifier the client would like to
see in the server's certificate that the server uses to sign the OCSP
response.=20

> -----Original Message-----
> From: Sean Turner [mailto:[e-mail]]=20
> Sent: Wednesday, August 19, 2009 8:59 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>=20
>=20
>=20
> Manger, James H wrote:
> >> What do you recommend we do: Forego clients stating the curves or=20
> >> define new OIDs?
> >=20
> > or allow the OIDs from subjectPublicKeyInfo.algorithm as=20
> well signature OIDs.
>=20
> This was where I was  going.
>=20
> > I have not thought about EC curves hard enough to really answer=20
> > Santosh's question.
> > A proper solution would get a bit complex, particularly as I don't=20
> > think there is an easy (or defined) way to match Alg.Id parameters,=20
> > let alone the signature-vs-key Alg.Id. issue.
> >=20
> > My gut feeling is that a client providing a list of OIDs=20
> would cover=20
> > the bulk of use cases, and the complexity to handle the rest is=20
> > unlikely to be worthwhile. I would specify a very simple=20
> syntax with=20
> > no parameter-based matching.
> >=20
> > PreferredSignatureAlgorithms ::=3D SEQUENCE OF OBEJCT=20
> IDENTIFIER This is=20
> > a list of values that the client can support in an OCSP response=20
> > Signatue.signatureAlgorithm.algorithm field -- from most to=20
> least preferred.
> >=20
> >=20
> > If necessary in the future, you could allow SPKI alg OIDs and/or EC=20
> > curve OIDs in the same list. It would not really match the=20
> semantics=20
> > of the preferred-signature-algorithms extension, but it would be=20
> > backwardly compatible (a server expecting only signature OIDs would=20
> > simply ignore the non-signature OIDs).
> >=20
> >=20
> > P.S. Why is PreferredSignatureAlgorithms a SEQUENCE with a single=20
> > field. This seems like an unnecessary extra SEQUENCE wrapping --=20
> > unless you might want to extend the type later, adding more fields.=20
> > However, in that case, you would probably just define a new=20
> extension.
> > Perhaps change
> >>From  : PreferredSignatureAlgorithms ::=3D SEQUENCE { Algorithms=20
> >>SEQUENCE OF
> > Alg.Id. }
> > to    : PreferredSignatureAlgorithms ::=3D SEQUENCE OF Alg.Id.
> > [or to: PreferredSignatureAlgorithms ::=3D SEQUENCE OF OBJECT=20
> > IDENTIFIER]
>=20
> How about something like:
>=20
> PreferredSignatureAlgorithms ::=3D SEQUENCE OF=20
> PreferredSignatureAlgorithm
>=20
> PreferredSignatureAlgorithm ::=3D SEQUENCE {
>    sigIdentifier   AlgorithmIdentifier,
>    certIdentifier  AlgorithmIdentifier OPTIONAL }
>=20
> sigIdentifier is the identifier the client would like to see=20
> in the signature.  e.g., In this AlgorithmIdentifer=20
> algorithm=3Decdsa-with-sha256 and parameters are absent.
>=20
> certIdentifier is the identifier the client would like to see=20
> in the server's certificate that the server uses to sign the=20
> OCSP response.=20
> e.g., In this AlgorithmIdentifier algorithm=3Did-ecPublicKey=20
> and parameters=3D secp256r1.
>=20
> certIdentifier is optional for those algs that don't need it.
>=20
> With this information the server would be able to easily tell=20
> what it's being asked to do.  Use this algorithm here and=20
> this certificate to do it.
>=20
> spt
>=20
> > James Manger
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JCxI4l071871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 05:59:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JCxIt2071870; Wed, 19 Aug 2009 05:59:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7JCxA0n071857 for <[e-mail]>; Wed, 19 Aug 2009 05:59:17 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31004 invoked from network); 19 Aug 2009 12:59:09 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.241.4.112 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 19 Aug 2009 12:59:09 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: n4nAV28VM1mrQBgukYnnD7FBAoTg376LGXYovAkGm75taKXJrftk9jrgFeqOHZzUzOJdYnHg5ohFmKSkKcu4S9O7mrcZ2.0ZQtQWWy8_dc2K0u_s2qBo0DxE8zJ6PRlTp9nFcrhAFnJ5h5xxVBkflYjATaXqkVi9IRDCl9fFFOqDDquu36fJVBL0JJMbh5sKXH6eozgZ_t7uCLRy89UHVR6I8utOgP0KBVHKY56SrdpPNG9UxQ4dtRxWynChnvT9z75xW6rEhXW5e19TzDcyP6jXzz9Bj7e7_SHGDUC9cykbcLgrUkuxF2nitSMD6GsHQ6ARJUgKAFBcIEd5tyZBfJO4OgKpr48KmTFWDS_Yjg--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Wed, 19 Aug 2009 08:59:08 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Manger, James H wrote:
>> What do you recommend we do: Forego clients stating the curves or
>> define new OIDs?
> 
> or allow the OIDs from subjectPublicKeyInfo.algorithm as well signature OIDs.

This was where I was  going.

> I have not thought about EC curves hard enough to really answer Santosh's 
> question.
> A proper solution would get a bit complex, particularly as I don't think there 
> is an easy (or defined) way to match Alg.Id parameters, let alone the 
> signature-vs-key Alg.Id. issue.
> 
> My gut feeling is that a client providing a list of OIDs would cover the bulk 
> of use cases, and the complexity to handle the rest is unlikely to be 
> worthwhile. I would specify a very simple syntax with no parameter-based 
> matching.
> 
> PreferredSignatureAlgorithms ::= SEQUENCE OF OBEJCT IDENTIFIER
> This is a list of values that the client can support in an OCSP response 
> Signatue.signatureAlgorithm.algorithm field -- from most to least preferred.
> 
> 
> If necessary in the future, you could allow SPKI alg OIDs and/or EC curve OIDs 
> in the same list. It would not really match the semantics of the 
> preferred-signature-algorithms extension, but it would be backwardly 
> compatible (a server expecting only signature OIDs would simply ignore the 
> non-signature OIDs).
> 
> 
> P.S. Why is PreferredSignatureAlgorithms a SEQUENCE with a single field. This 
> seems like an unnecessary extra SEQUENCE wrapping -- unless you might want to 
> extend the type later, adding more fields. However, in that case, you would 
> probably just define a new extension.
> Perhaps change
>>From  : PreferredSignatureAlgorithms ::= SEQUENCE { Algorithms SEQUENCE OF 
> Alg.Id. }
> to    : PreferredSignatureAlgorithms ::= SEQUENCE OF Alg.Id.
> [or to: PreferredSignatureAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER]

How about something like:

PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {
   sigIdentifier   AlgorithmIdentifier,
   certIdentifier  AlgorithmIdentifier OPTIONAL }

sigIdentifier is the identifier the client would like to see in the 
signature.  e.g., In this AlgorithmIdentifer algorithm=ecdsa-with-sha256 
and parameters are absent.

certIdentifier is the identifier the client would like to see in the 
server's certificate that the server uses to sign the OCSP response. 
e.g., In this AlgorithmIdentifier algorithm=id-ecPublicKey and 
parameters= secp256r1.

certIdentifier is optional for those algs that don't need it.

With this information the server would be able to easily tell what it's 
being asked to do.  Use this algorithm here and this certificate to do it.

spt

> James Manger



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JClxQH071092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 05:47:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JClxQK071091; Wed, 19 Aug 2009 05:47:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7JClwHo071084 for <[e-mail]>; Wed, 19 Aug 2009 05:47:58 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 45527 invoked from network); 19 Aug 2009 12:47:58 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.241.4.112 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 19 Aug 2009 12:47:57 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: LyLNPfUVM1m6i0Fx9XikvqqxcKUiGgpz64mHE8o1ckSheIrwVDmsnd9PTKj8liFImy1NPqg1j1jwrNcoFAyJ853MFib5B2yYrZCALj3czXy74wqQCcoMF3Mdh01V.zpMh3NOs4IopaQI0LsozG6aWx2YF._ifrImSP_DlKxbhXesX2DTSjH8LfoGE0s8ZsmzweT0Dn_MNO18TiKK4yjIPIVeWVXhfr6qaZ2fg84KcNVzerszhsddQWrbVsW48AJsqjf_lENkrEygpOGEs3xc73FTNQISEgEomgG94ysSFtUfcV2KBuA2xos8Td7D1GGrDfza3E3Ea8olgvW_5g1bwMyEziDD6O965JnQShyy
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Wed, 19 Aug 2009 08:47:57 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Manger, James H wrote:
> [Santosh] My suggestion is that it is appropriate to use the Alg ID and
> assert the parameters in spite of RFC 5480.  My reasoning is as follows.
> The ASN.1 permits it; we need it for interoperability; the RFC wants
> them absent when asserting in Signature or SIGNED MACRO since getting
> the parameters from those locations have proven to be vulnerable to
> substitution attack (at least in degenerate cases); they definitely are
> not authenticated.  But, the application in this I-D is different.
> Since the whole structure is unauthenticated, there is no harm in
> unauthenticated parameters as well.
> 
> 
> I disagree. The ASN.1 DOES NOT support using the same object id in different instances of the AlgorithmIdentifier structure with different parameter syntaxes. The ASN.1 may allow ANY syntax for the parameters, but the assumption (or explicit constraint -- depending on your version of ASN.1) is that the syntax is defined by the preceding object id.

I agree with James here.  Algorithm Identifier does allow you to define 
an algorithm with what ever parameters you want, but you just can't 
stick more parameters on the ecdsa-with-* OID.  The OIDs have been well 
defined/registered in RFC 3278, RFC 3279, RFC 5480, 
draft-ietf-pkix-sha2-dsa-ecdsa, draft-ietf-smime-3278bis (in RFC 
editor's queue), and draft-ietf-smime-new-asn (with IESG) which all say 
either NULL or absent parameters (depending on the hash alg).

> Some code will have tables mapping OID-to-parameter-syntax to automatically decode Alg.Id values. With Santosh's suggestion the code would need different tables depending on context: one table when decoding an Alg.Id in the PreferredSignatureAlgorithms type, and another table when decoding an Alg.Id in a Signature type. Yuck.
> 
> 
> It looks like what is really needed is a rule for matching acceptable combinations of signature algorithm and signing key properties (key algorithm and key length). To do that properly requires a new matching rule with its own syntax.
> 
> 
> 
> P.S. field names usually (must?) start with lower-case letters in ASN.1 so PreferredSignatureAlgorithms should be "SEQUENCE { algorithms SEQUENCE OF Alg.Id. }".
> 
> 
> James Manger
> [e-mail]
> Identity and security team — Chief Technology Office — Telstra



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JClYdH071067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 05:47:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JClY6I071066; Wed, 19 Aug 2009 05:47:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7JClQ4m071048 for <[e-mail]>; Wed, 19 Aug 2009 05:47:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 45006 invoked from network); 19 Aug 2009 12:47:25 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.241.4.112 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 19 Aug 2009 12:47:25 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: zMhfOHQVM1kt2PN2XYw5c1RG46xNA6YNAmJ92e6Ukn8Xb5Emt0zFQVr06xolUJzWiVXNGtTxiSqQpIUcOo.RpBa43K_DmlcXNDjfJ5pWhOZRPNSV_Ue8TLl7TxY_BIylkmy5ZukONdBBmIkGvyihCvx5D5.v_pg.ZHAjpognPV4bWG7JneCn0_GOxLbZPg4RYz17QyCVmjgUJioGhG9LK3tE9CSJdXekfmldBIst86QtZ6ZDLcM8uO5icOHtVv1oxa_Kc2QOEBVYtMv8MglQwE2fJ5gHZheFOxmmPI6glix4qoYNuw3QRLKx04FoVfj9Pb7OCrolFC805S8ldHrwrPxtg6zrt_16u3Y-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Wed, 19 Aug 2009 08:47:18 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: Stefan Santesson <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh Chokhani wrote:
> Sean,
> 
> See responses below. 
> 
>> -----Original Message-----
>> From: Sean Turner [mailto:[e-mail]] 
>> Sent: Tuesday, August 18, 2009 8:27 AM
>> To: Stefan Santesson
>> Cc: Santosh Chokhani; [e-mail]
>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>>
>> Stefan/Santosh,
>>
>> Jumping in mid-stream, but to fully specify what the client 
>> wants doesn't it need to specify the signing algorithm, the 
>> hashing algorithm,
>>   algorithms parameters and the key size?  If we need all 
>> four of these then I'd suggest AlgorithmIdentifier might not 
>> be the right mechanism for unsigned requests.
> 
> [Santosh] Since this is public key (vice private key) operation and
> since it is normally done in software, I do not think key size is
> required.  Note that we generally do not define key size for public key
> in certificates either.  It is implicit in the structure.

I think it is a private key operation in that the client is asking the 
server to use a particular private key.  There then might arise the case 
when the server supports a key size which the client does not.  In this 
case the client needs to tell the server "hey only use a private key 
this big otherwise I can't verify your signature".  If we're assuming 
the servers/clients support a particular private key size, then we ought 
to say what that size is.

On a new topic: Another concern I have is that there's a DoS attack when 
the attacker sends a really big bogus signture and the client has to 
spend time figuring this out.  We had a long discussion about this on 
the SMIME list.  We added a security consideration in 
draft-ietf-smime-3851bis as follows:

  Receiving agents that validate signatures and sending agents that
  encrypt messages, need to be cautious of cryptographic processing
  usage when validating signatures and encrypting messages using keys
  larger than those mandated in this specification.  An attacker could
  send certificates with keys which would result in excessive
  cryptographic processing, for example keys larger than those mandated
  in this specification, which could swamp the processing element.
  Agents which use such keys without first validating the certificate
  to a trust anchor are advised to have some sort of cryptographic
  resource management system to prevent such attacks.


>> I say unsigned requests because if the request is signed then 
>> you'd know the signing and hashing algorithm from the 
>> signature as well as the parameters and key size from the 
>> certificate.  None of the signing algorithm parameters I am 
>> aware of include key size.  Almost all are NULL.
> 
> [Santosh] Unless I do not read the I-D properly, this has nothing to do
> with client signing requests.  It is a new request extension (and not a
> request entry extension).  Request Vs request entry extension should be
> clarified in the I-D (Seth also noted the ambiguity).

I understand this, my point really was that you need to fully specify 
the four choices or infer them.

>> If you still wanted to use algorithm identifier for unsigned, 
>> then for the ECDSA algs you'd need to assume that the 
>> recommendations in RFC 5480 are followed.  That is if you 
>> request ECDSA with no parameters in an algorithm identifier 
>> you know it's ECDSA, SHA-256, P-256, and 256-bit key.
> 
> [Santosh] The ecdsa-with-SHA256 does not mean P-256.  RFC 5480 itself
> has two other curves that can be used with it.  There could be other
> curves since the RFC does not restrict you.

There are 2 tables in RFC 5480.  The 1st lists the possibilities for 
ECDSA but the 2nd (on page 10) provides some RECOMMENDED key sizes, 
hashes, and curves for a given # of bits of security.  What I was saying 
is that if we use that table, then we could infer everything.  But, the 
group will need to agree to that.

> [Santosh] My suggestion is that it is appropriate to use the Alg ID and
> assert the parameters in spite of RFC 5480.  My reasoning is as follows.
> The ASN.1 permits it; we need it for interoperability; the RFC wants
> them absent when asserting in Signature or SIGNED MACRO since getting
> the parameters from those locations have proven to be vulnerable to
> substitution attack (at least in degenerate cases); they definitely are
> not authenticated.  But, the application in this I-D is different.
> Since the whole structure is unauthenticated, there is no harm in
> unauthenticated parameters as well. 

I disagree with this adding additional (see response to James' email).

I agree the parameters don't need to be authenticated.

>> I'm not sure how you infer the key size from 
>> sha256WithRSAEncryption or id-dsa-with-sha256?
>>
>> Maybe the way ahead is to include the clients cert in the request?
>>
>> spt
>>
>>
>> Stefan Santesson wrote:
>>> Where is it stated that parameters must be absent?
>>> I tried to find it but failed.
>>> It sounds strange as they are defined by the alg OID.
>>>
>>> Anyway, for clarity, I understand your position that you think the 
>>> defined
>>> ASN.1 syntax is OK if we add a note saying that the client SHOULD 
>>> specify the curve. We could then also add text warning for the 
>>> consequences if the client does not specify the curve.
>>>
>>> Would that work?
>>>
>>> /Stefan
>>>
>>>
>>> On 09-08-17 10:56 PM, "Santosh Chokhani" 
>> <[e-mail]> wrote:
>>>> Stefan,
>>>>
>>>> First of all: That is what I have been saying: "The client 
>> needs to 
>>>> specify the curve."
>>>>
>>>> But, when you go to 5480, the curves are specified for the 
>> Alg ID in 
>>>> SPKI.  If you look down at the ASN.1 for SIGNED MACRO type 
>> Alg ID, it 
>>>> says parameters are absent.  That is why note at the start of this 
>>>> thread on ocspagility-02 and I quote "If we have argument on 
>>>> populating these OIDs with parameters (e.g., based on RFC 
>> 5480), we 
>>>> may need to come up with different ASN.1."
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefan Santesson [mailto:[e-mail]]
>>>>> Sent: Monday, August 17, 2009 4:47 PM
>>>>> To: Santosh Chokhani
>>>>> Cc: [e-mail]
>>>>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>>>>>
>>>>> Santosch,
>>>>>
>>>>>
>>>>> On 09-08-17 10:39 PM, "Santosh Chokhani"
>>>>> <[e-mail]> wrote:
>>>>>
>>>>>> Stefan,
>>>>>>
>>>>>> Shall I assume that you will add a note on the type of Alg ID?
>>>>>>
>>>>> Yes, I can do that.
>>>>>
>>>>>> As to 5480, it has lot of curves in it.  If a client did
>>>>> not ask for a
>>>>>> curve and server used one of these curves, the client may not 
>>>>>> understand the curve and hence will not be able to process
>>>>> the signature.
>>>>>
>>>>> But the client can specify curve, and in that case the 
>> server would 
>>>>> know what the client wants, right?. That feels good 
>> enough for me. 
>>>>> I'm not sure what more you would suggest that we do?
>>>>>
>>>>> /Stefan
>>>>>
>>>>>
>>>>>
>>>
>>>
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7J4ltJ4043418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 21:47:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7J4ltSd043417; Tue, 18 Aug 2009 21:47:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7J4lh5H043408 for <[e-mail]>; Tue, 18 Aug 2009 21:47:54 -0700 (MST) (envelope-from [e-mail])
Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipai.vtcif.telstra.com.au with ESMTP; 19 Aug 2009 14:47:41 +1000
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 35FDB1DA81 for <[e-mail]>; Wed, 19 Aug 2009 14:47:41 +1000 (EST)
Received: from WSMSG3755.srv.dir.telstra.com (wsmsg3755.in.telstra.com.au [172.49.40.196]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA21311 for <[e-mail]>; Wed, 19 Aug 2009 14:47:40 +1000 (EST)
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Wed, 19 Aug 2009 14:47:40 +1000
From: "Manger, James H" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Wed, 19 Aug 2009 14:47:35 +1000
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Index: Acof/zu672ERb1kjTFGfum2I4fdDBQACOlKAABnofBAAAc7LAAACxqTw
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US, en-AU
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0029_01CA20DB.FD7D1480"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_NextPart_000_0029_01CA20DB.FD7D1480
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit

> What do you recommend we do: Forego clients stating the curves or
> define new OIDs?

or allow the OIDs from subjectPublicKeyInfo.algorithm as well signature OIDs.

I have not thought about EC curves hard enough to really answer Santosh's 
question.
A proper solution would get a bit complex, particularly as I don't think there 
is an easy (or defined) way to match Alg.Id parameters, let alone the 
signature-vs-key Alg.Id. issue.

My gut feeling is that a client providing a list of OIDs would cover the bulk 
of use cases, and the complexity to handle the rest is unlikely to be 
worthwhile. I would specify a very simple syntax with no parameter-based 
matching.

PreferredSignatureAlgorithms ::= SEQUENCE OF OBEJCT IDENTIFIER
This is a list of values that the client can support in an OCSP response 
Signatue.signatureAlgorithm.algorithm field -- from most to least preferred.


If necessary in the future, you could allow SPKI alg OIDs and/or EC curve OIDs 
in the same list. It would not really match the semantics of the 
preferred-signature-algorithms extension, but it would be backwardly 
compatible (a server expecting only signature OIDs would simply ignore the 
non-signature OIDs).


P.S. Why is PreferredSignatureAlgorithms a SEQUENCE with a single field. This 
seems like an unnecessary extra SEQUENCE wrapping -- unless you might want to 
extend the type later, adding more fields. However, in that case, you would 
probably just define a new extension.
Perhaps change
>From  : PreferredSignatureAlgorithms ::= SEQUENCE { Algorithms SEQUENCE OF 
Alg.Id. }
to    : PreferredSignatureAlgorithms ::= SEQUENCE OF Alg.Id.
[or to: PreferredSignatureAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER]

James Manger

------=_NextPart_000_0029_01CA20DB.FD7D1480
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIbMzCCBjsw
ggUjoAMCAQICChdxQLUAAAAAAXowDQYJKoZIhvcNAQEFBQAwFzEVMBMGA1UEAxMMTWVzc2FnaW5n
IENBMB4XDTA5MDMzMDA0MDM1NloXDTEwMDMzMDA0MDM1NlowEjEQMA4GA1UEAxMHYzc5OTg3ODCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO8P/+Fi1PoZEwtviknjbBwidlGRLsFmvBzs
17SVVVm9mnqftyvY8SxCbOtXrhG+8+OyMK585h7PaNW3u0v9mK027UC+uPFEOU8SEEQmXLW1pm6L
et1uzuTEEYIDDtjcMEfYLkFnaV5bNBiCeyWEHHN7aiqMi8a6RORrNlz9W/Jl261e1m+OlBp1ERwl
LpqiuCa6xTh1uferf5v0vmerUUuontzdiS8m0Xm0maA/lKsArsUL0suD2Eq87karqJoXzcN0irHu
F7zfOYclo4Fn/1QFuYaY8V2n7QQUNNrbsTkLOzm4flO6DNgtbIOXLZcY2JR6cKFXgKhAnQXJwiuO
w1MCAwEAAaOCA4wwggOIMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQU8lC4r/gvSB0BMMqVbVhIirsC
L4wwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhNSOIoLt31OF9YMYgsa8XIWHuy1+htX/D4L9
+g4CAWQCAQowHwYDVR0jBBgwFoAUjrE+SRWrx5IE38/Ol+qJtJ4lVREwggEnBgNVHR8EggEeMIIB
GjCCARagggESoIIBDoaBxmxkYXA6Ly8vQ049TWVzc2FnaW5nJTIwQ0EsQ049d3NjYXMwMDEyLENO
PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0
aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv
bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZDaHR0cDovL3dzY2Fz
MDAxMi5jb3JlLmRpci50ZWxzdHJhLmNvbS9DZXJ0RW5yb2xsL01lc3NhZ2luZyUyMENBLmNybDCC
AUEGCCsGAQUFBwEBBIIBMzCCAS8wgbwGCCsGAQUFBzAChoGvbGRhcDovLy9DTj1NZXNzYWdpbmcl
MjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29u
ZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxzdHJhLERDPWNvbT9jQUNlcnRpZmljYXRl
P2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBuBggrBgEFBQcwAoZiaHR0
cDovL3dzY2FzMDAxMi5jb3JlLmRpci50ZWxzdHJhLmNvbS9DZXJ0RW5yb2xsL3dzY2FzMDAxMi5j
b3JlLmRpci50ZWxzdHJhLmNvbV9NZXNzYWdpbmclMjBDQS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUH
AwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBYBgNVHREEUTBPoCwGCisGAQQBgjcUAgOg
HgwcYzc5OTg3OEBjb3JlLmRpci50ZWxzdHJhLmNvbYEfSmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxz
dHJhLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEALZDeZpos2zSrCoLRDx1Cu6f7xbqf/Obpi+aAuqJu
LiHWw/gwyy0lY9KBa4naedOAA0REylEP5A/fwXQa/wEzGtqY5naaeEurSOiWWTOcsmg8ay9bWSS9
KUzUoaRhYr5Fh1eYU9Gu+RuyzPRoRYE4Iw9kWT0fTSPRWmNTJLX644Ja1qelxQMw1nurrUAyaSEb
tR8TFqdegghVhEqHjSWAF/M+DxpXragF4tM1q97tXcKtpSMa+ohibRDocegXru+MhKrFyUm/TP0H
kG4q0HiRHTlyXEiPyiNKbCFJxPeh1eOGKKEcABDmOz2tzrQX45QUGagzv8m42jpX1DNEzeyIdTCC
BoEwggVpoAMCAQICChdwbt4AAAAAAXkwDQYJKoZIhvcNAQEFBQAwFzEVMBMGA1UEAxMMTWVzc2Fn
aW5nIENBMB4XDTA5MDMzMDA0MDMwMFoXDTEwMDMzMDA0MDMwMFowEjEQMA4GA1UEAxMHYzc5OTg3
ODCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk6xFOFUU5KUvl92YXce4jF7DLPOHfb
8HttBGUDqnn1btHtMNsR2+aN4EHYgCkxCk+bVidmI9iael9f+DwuwG3CtidUfnJkSbBMtnt52r/Z
yBn9QVwJxPq58BycssAI7qnBSDEQp3Um1vQlUSJP+U89I+5G8QpBParV+uNeMxksZnpb1WwxyHID
DJrTfJQpctW3TdKAFJBRxpT+zw/gAGUNWER7H1SSWbAmnLRfODD/EtcnuXKEYOGjT1nAwmb81yZs
MHKuHHHwP8ae3M+B6qfsuj9MrsrG/AhwbxvUYUoofxEPZQD8oMGvxMaCdXIziLgaNll4Tu32W1qc
1lohhb0CAwEAAaOCA9IwggPOMAsGA1UdDwQEAwIFIDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3
DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFPdI
bbMdMWgxNFd5S4gUmvNtA9m5MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCITUjiKC7d9ThfWD
GILGvFyFh7stfoTLh2ODx+odAgFkAgEEMB8GA1UdIwQYMBaAFI6xPkkVq8eSBN/PzpfqibSeJVUR
MIIBJwYDVR0fBIIBHjCCARowggEWoIIBEqCCAQ6GgcZsZGFwOi8vL0NOPU1lc3NhZ2luZyUyMENB
LENOPXdzY2FzMDAxMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj
ZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxzdHJhLERDPWNvbT9jZXJ0
aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p
bnSGQ2h0dHA6Ly93c2NhczAwMTIuY29yZS5kaXIudGVsc3RyYS5jb20vQ2VydEVucm9sbC9NZXNz
YWdpbmclMjBDQS5jcmwwggFBBggrBgEFBQcBAQSCATMwggEvMIG8BggrBgEFBQcwAoaBr2xkYXA6
Ly8vQ049TWVzc2FnaW5nJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y29yZSxEQz1kaXIsREM9dGVsc3RyYSxEQz1j
b20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw
bgYIKwYBBQUHMAKGYmh0dHA6Ly93c2NhczAwMTIuY29yZS5kaXIudGVsc3RyYS5jb20vQ2VydEVu
cm9sbC93c2NhczAwMTIuY29yZS5kaXIudGVsc3RyYS5jb21fTWVzc2FnaW5nJTIwQ0EuY3J0MBMG
A1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwWAYDVR0RBFEw
T6AsBgorBgEEAYI3FAIDoB4MHGM3OTk4NzhAY29yZS5kaXIudGVsc3RyYS5jb22BH0phbWVzLkgu
TWFuZ2VyQHRlYW0udGVsc3RyYS5jb20wDQYJKoZIhvcNAQEFBQADggEBAA2df1z0HL7kzTTXbX9r
YPbQ2LxN339XNf6THqbKXHfEnsj72nIFvflxkpHiR0PDQi9IVTushhY81Oumkb64II3hDqCnWztt
fllQDrEQtF9xUVNBISQD9H1i3j8zI5LIiQOaGYdrf5ebEf16g7Y2Apwfo9V9bY09T50ztJvi5W56
cTZEWeXsvYSopvTFT620rro+V549ZBSMAn6qlg1dOpiWCB0MJsCXXp+7kpCTtuM9dafpJRNI5w9S
8QoCyQlfH94U1uRqQ21zixSDLbO0gDDglSLdvsp0tK44+ZRHHzVFzfSpX/Ls0/bKEqXq+ZW3rEPb
TfNCgDILTliP0QsYi3YwggcKMIIE8qADAgECAhA9Ft3ZAidOrEiRFBv9SOnSMA0GCSqGSIb3DQEB
BQUAMIGnMSEwHwYJKoZIhvcNAQkBFhJSb290Q0FAdGVsc3RyYS5jb20xCzAJBgNVBAYTAkFVMREw
DwYDVQQIEwhWaWN0b3JpYTESMBAGA1UEBxMJTWVsYm91cm5lMRAwDgYDVQQKEwdUZWxzdHJhMRkw
FwYDVQQLExBOZXR3b3JrIFNlY3VyaXR5MSEwHwYDVQQDExhUZWxzdHJhIEludGVybmFsIFJvb3Qg
Q0EwHhcNMDAxMTE2MDIyOTEzWhcNMTAxMTE2MDIzMTU1WjCBpzEhMB8GCSqGSIb3DQEJARYSUm9v
dENBQHRlbHN0cmEuY29tMQswCQYDVQQGEwJBVTERMA8GA1UECBMIVmljdG9yaWExEjAQBgNVBAcT
CU1lbGJvdXJuZTEQMA4GA1UEChMHVGVsc3RyYTEZMBcGA1UECxMQTmV0d29yayBTZWN1cml0eTEh
MB8GA1UEAxMYVGVsc3RyYSBJbnRlcm5hbCBSb290IENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A
MIICCgKCAgEAnpwjjsFHf+79TWueHlUdxK3+abffdE4bUBL+QuaNnWZ9iPyQU08vqhENwyIJO0nx
AXeGLtjKsbzOu3wBxKCuefjb8XSoo4bOQQ5c5Rsf3hs4v+I09zwFgF+pxNV6DpOiwIB9XQgz0lpu
joZVBl6m5ugVk+ADio10cD8ug8OyZvUURiHwgigHSUgqPcj+bqlJFMLbdg9mgAxEx5Ty1xRlKJ17
0CMnUeAV419eQrg0+GPCAt7nViNxW4SYR/9riFtMfavvBYjxvHbcq2v3PBfvhGAxFLWChKDm0wg2
qqt4wLm4VNrE+desJF+XOlqBi0IHQy5mE8KhWMMhW6Bbag5mQfPZVYwDXJ+TSprxRTkQ0KYU2vLF
nBo0f5gqpcp4tiBRba6VDe/RmGgUUYCaBB4dh7v/Q1yxQrinUOHMqxVepZugobszXin1pRZ/Qy3D
tCfJzO6C85gsN+bcGlfzajFLTV9VGo283+0g3HIahQdYG83PvvhZF8eR9+fohwwasYtKKiSl40z5
I46VrainDdjL1l4adwbjnS0nDv3mL9kbSyJLmRpfE5Nb3+BVUFErDV8a23KHr1mdAUMEKHU4Y8Ep
g+q9vTVZsAJfRMgNc5+bzd1C65j+1FhOh3xKgwlu1qvux2BAtOYIRwUf59tEuJELM5iszyPThURE
my/eapk1SlcCAwEAAaOCAS4wggEqMBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAP
BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQS3FKmReD1ql/Ger9J5nUZcw29+TCBwwYDVR0fBIG7
MIG4MFmgV6BVhlNodHRwOi8vd3NjYXIwMDAxLmNvcmUuZGlyLnRlbHN0cmEuY29tL0NlcnRFbnJv
bGwvVGVsc3RyYSUyMEludGVybmFsJTIwUm9vdCUyMENBLmNybDBboFmgV4ZVZmlsZTovL1xcV1ND
QVIwMDAxLmNvcmUuZGlyLnRlbHN0cmEuY29tXENlcnRFbnJvbGxcVGVsc3RyYSUyMEludGVybmFs
JTIwUm9vdCUyMENBLmNybDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAkysT
049btivCdrHQWHbsi7yg1O/gkK4RPY5kS3tbsJiMlYFNxpPuQL30/MKNMNubP6lBNucZBCRK8+J7
XtuBltfznqe6zvWtcNIWUWbBsZlJ7lM/rYuKFkU/EYnK8sCHmDwZtxd53Vb1BGmlGZ8ORJSggZm8
LKqhyQLXTr7fdvSBIfoOEEUhVNPu3qBul+QjtwVmnhYgX4IXxM624nZTs9BoSe++wGJALHZJ5CJb
6FIAC4t5dY2PJMHeAs84kybkmb3LfM1gTEpeZYFrH50pHxsLocapb/gR7K0NPHzQnLc6MeYdIHxm
oLWIWEsb4kYKNlhip4ddC2qnwhT7ynp8vWVhrQRwr5LVvmMSSyUIYJn0+QV6q4ptfvO4v2J6RkDv
APGJdfx0WD+4N2gQ/xrRGmjJn73efCzpzjffy0SH1Xjj5d5+ofR7wbu6i5iB1aZdeaPj95flfy7e
BW3z/3r0MboP624XiDqlLF+FKt8lh0nh38vECPBUh6U9BH5bp2c36my2b1ZdDs/ryg1Rs9o0inpU
q7yexHwGIKiEtqKGNGL2Osxm5NDn8OvCY0FsIchdzvCORUYEQV85nbW1SkTcms+QjYfptcA72bdZ
KDfpvSK1tArBqWAdUeJlwB9uC6NTSazXTNB3fGgGvNl4y6hi82oRAfaZKKLYuMZd/C2eOuAwggdd
MIIFRaADAgECAgphC9E1AAAAAAAaMA0GCSqGSIb3DQEBBQUAMIGnMSEwHwYJKoZIhvcNAQkBFhJS
b290Q0FAdGVsc3RyYS5jb20xCzAJBgNVBAYTAkFVMREwDwYDVQQIEwhWaWN0b3JpYTESMBAGA1UE
BxMJTWVsYm91cm5lMRAwDgYDVQQKEwdUZWxzdHJhMRkwFwYDVQQLExBOZXR3b3JrIFNlY3VyaXR5
MSEwHwYDVQQDExhUZWxzdHJhIEludGVybmFsIFJvb3QgQ0EwHhcNMDYwNTIzMDMxNDM0WhcNMTAx
MTE2MDIzMTU1WjAXMRUwEwYDVQQDEwxNZXNzYWdpbmcgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQCwoF8xB3u77NXnoqaWEMkvFMsxiUyCDcfXbUdQzEPsEaj5ldeR4lRBVeiADIDN
R0bnvFOGQSrmNK7i5KugI7EfA0h6giZ8Oh3lCx1kpzrPswIJOCwbKpjqgjT6sJXa+plLPmLm2j6v
B6Dzye1SotWzeCMWnwmSdIT8LbSsz5QVS7K/eck0CWgIxwiOvgUNGfDNJLfBzFIotvxq1olQL8i2
m6J8s9T9Fx7LGvju9g25M4rghJW9YPGSekJcxHmVEvbYUDNnKQHFJKQ8U/vC5KSgfGrMivQg6O7m
ucKnPb8s+1Wp5SkOjOCInaqtlGlWsLRcubOueJgcA/oae7sr1vOFAgMBAAGjggMYMIIDFDAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBSOsT5JFavHkgTfz86X6om0niVVETALBgNVHQ8EBAMCAcYw
EAYJKwYBBAGCNxUBBAMCAQAwgeMGA1UdIwSB2zCB2IAUEtxSpkXg9apfxnq/SeZ1GXMNvfmhga2k
gaowgacxITAfBgkqhkiG9w0BCQEWElJvb3RDQUB0ZWxzdHJhLmNvbTELMAkGA1UEBhMCQVUxETAP
BgNVBAgTCFZpY3RvcmlhMRIwEAYDVQQHEwlNZWxib3VybmUxEDAOBgNVBAoTB1RlbHN0cmExGTAX
BgNVBAsTEE5ldHdvcmsgU2VjdXJpdHkxITAfBgNVBAMTGFRlbHN0cmEgSW50ZXJuYWwgUm9vdCBD
QYIQPRbd2QInTqxIkRQb/Ujp0jCBwwYDVR0fBIG7MIG4MFmgV6BVhlNodHRwOi8vd3NjYXIwMDAx
LmNvcmUuZGlyLnRlbHN0cmEuY29tL0NlcnRFbnJvbGwvVGVsc3RyYSUyMEludGVybmFsJTIwUm9v
dCUyMENBLmNybDBboFmgV4ZVZmlsZTovL1xcV1NDQVIwMDAxLmNvcmUuZGlyLnRlbHN0cmEuY29t
XENlcnRFbnJvbGxcVGVsc3RyYSUyMEludGVybmFsJTIwUm9vdCUyMENBLmNybDCCARUGCCsGAQUF
BwEBBIIBBzCCAQMwfgYIKwYBBQUHMAKGcmh0dHA6Ly93c2NhcjAwMDEuY29yZS5kaXIudGVsc3Ry
YS5jb20vQ2VydEVucm9sbC9XU0NBUjAwMDEuY29yZS5kaXIudGVsc3RyYS5jb21fVGVsc3RyYSUy
MEludGVybmFsJTIwUm9vdCUyMENBLmNydDCBgAYIKwYBBQUHMAKGdGZpbGU6Ly9cXFdTQ0FSMDAw
MS5jb3JlLmRpci50ZWxzdHJhLmNvbVxDZXJ0RW5yb2xsXFdTQ0FSMDAwMS5jb3JlLmRpci50ZWxz
dHJhLmNvbV9UZWxzdHJhJTIwSW50ZXJuYWwlMjBSb290JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUA
A4ICAQB2Gd568tcY04j08RWRSd32wdJeS42EDLl9mDqFn8xOyF4ODrPNKCymhp5ZxKQfE06YQBCa
qvJBVDiV+qFehjvEns0RmZwvAbZalqWeSwu66P8NbbXu0108ubTyiECoIeRGZIHXblDQ3BfkR3e4
8Ise+DOPCIA/PjDdKJ3jtR+1XTL0f/i191k/bjGts+07MOQWuBFssTL0b0MD5l/fs2MDXWClozlM
dgI407z+e6bk5JyiwdEALM0TlXSzim/SfGu70Ks20XDUpDiV/1RPE/YVDbVsCdVeG5S0tuQu3PGw
dDpb4ROGvrusT4fIP/uYh7/vRwZp6LCf2e8rUBgWo+mPva0FJm5uiJgmHkXX+GV7LVEfAjtlE0gU
pfsnx/2PUbyMi9AH1kZxnlJvdD2yL/qTwMb087dqWigmTPO+pIq4MZaTQdQFxEfvHdW6fx2yMUcG
15kw7lmYcYD8zSCbWMPZX9c3sQTWo5OK70ZPpA3xnHwyMZbpXCZ84BE8M9JoW32DHMGIobuSEgh8
DKdrfaMS9K2VcYRS79oA19QASVLnIZGkSWyDsfJ1FIDWPRz7GLZVeiqFObL6pWjH6zi5pHNX3nc+
u/XowTcy4XDEAaNN4apuxNuzi4Rhw+8tCiG3h4YIbx9B8jjXno/0O5IPSMx4eJfoZikbLJKE9xMn
uSmSrjGCAoQwggKAAgEBMCUwFzEVMBMGA1UEAxMMTWVzc2FnaW5nIENBAgoXcUC1AAAAAAF6MAkG
BSsOAwIaBQCgggE0MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5
MDgxOTA0NDczNVowIwYJKoZIhvcNAQkEMRYEFHKNyv+ANADB/TdHx8JOF5q1y8UiMDQGCSsGAQQB
gjcQBDEnMCUwFzEVMBMGA1UEAxMMTWVzc2FnaW5nIENBAgoXcG7eAAAAAAF5MDYGCyqGSIb3DQEJ
EAILMSegJTAXMRUwEwYDVQQDEwxNZXNzYWdpbmcgQ0ECChdwbt4AAAAAAXkwZwYJKoZIhvcNAQkP
MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwDQYJKoZIhvcNAQEBBQAEggEAFWEx
0ZZNCcsPY+AKIsX1U7pxzgEZIZ2Du32b8TC4qtRyCtqr0oevWJ//09GjFsMeoomoFBlEArHKIXKs
eX1iqanDLZcIJ4yinvh/DuGZNL4BWqzSBcdJmTzwmgjT/eykUp7nST4tnbx6FdDQ9zZOhAguwTas
8uXKuL3tSrgVLaPSKb8OQQ0I2jfulx6wT+AtB0hR9gIbYOfN5BUBOVDKdIJgeslwL11ixy/acLS4
24OTXWLmirgVVnvWb9dV5C86JSTab14SEwK148FbxCfhdMD/gcXJFvzxo3j1gTQPuIwc6/eDq8Ph
Nkq2+20X7vebzMudjF6I8tafH5JIaVaxnwAAAAAAAA==

------=_NextPart_000_0029_01CA20DB.FD7D1480--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7J2kWL6037084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 19:46:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7J2kWSN037083; Tue, 18 Aug 2009 19:46:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7J2kKGd037075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Aug 2009 19:46:31 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 7876b8a4.2446805936.208753.00-004.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Tue, 18 Aug 2009 20:46:31 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Tue, 18 Aug 2009 22:46:17 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
thread-index: Acof/zu672ERb1kjTFGfum2I4fdDBQACOlKAABnofBAAAc7LAA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

What do you recommend we do: Forego clients stating the curves or define
new OIDs?=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Manger, James H
> Sent: Tuesday, August 18, 2009 10:28 PM
> To: [e-mail]
> Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>=20
> [Santosh] My suggestion is that it is appropriate to use the=20
> Alg ID and assert the parameters in spite of RFC 5480.  My=20
> reasoning is as follows.
> The ASN.1 permits it; we need it for interoperability; the=20
> RFC wants them absent when asserting in Signature or SIGNED=20
> MACRO since getting the parameters from those locations have=20
> proven to be vulnerable to substitution attack (at least in=20
> degenerate cases); they definitely are not authenticated. =20
> But, the application in this I-D is different.
> Since the whole structure is unauthenticated, there is no=20
> harm in unauthenticated parameters as well.
>=20
>=20
> I disagree. The ASN.1 DOES NOT support using the same object=20
> id in different instances of the AlgorithmIdentifier=20
> structure with different parameter syntaxes. The ASN.1 may=20
> allow ANY syntax for the parameters, but the assumption (or=20
> explicit constraint -- depending on your version of ASN.1) is=20
> that the syntax is defined by the preceding object id.
>=20
> Some code will have tables mapping OID-to-parameter-syntax to=20
> automatically decode Alg.Id values. With Santosh's suggestion=20
> the code would need different tables depending on context:=20
> one table when decoding an Alg.Id in the=20
> PreferredSignatureAlgorithms type, and another table when=20
> decoding an Alg.Id in a Signature type. Yuck.
>=20
>=20
> It looks like what is really needed is a rule for matching=20
> acceptable combinations of signature algorithm and signing=20
> key properties (key algorithm and key length). To do that=20
> properly requires a new matching rule with its own syntax.
>=20
>=20
>=20
> P.S. field names usually (must?) start with lower-case=20
> letters in ASN.1 so PreferredSignatureAlgorithms should be=20
> "SEQUENCE { algorithms SEQUENCE OF Alg.Id. }".
>=20
>=20
> James Manger
> [e-mail]
> Identity and security team - Chief Technology Office - Telstra
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7J2STTf036421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 19:28:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7J2STXk036420; Tue, 18 Aug 2009 19:28:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7J2SI7V036397 for <[e-mail]>; Tue, 18 Aug 2009 19:28:28 -0700 (MST) (envelope-from [e-mail])
Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipbi.vtcif.telstra.com.au with ESMTP; 19 Aug 2009 12:28:16 +1000
Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id C6CD21DA86 for <[e-mail]>; Wed, 19 Aug 2009 12:28:15 +1000 (EST)
Received: from WSMSG3751.srv.dir.telstra.com (wsmsg3751.srv.dir.telstra.com [172.49.40.172]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id A6CD341D22 for <[e-mail]>; Wed, 19 Aug 2009 12:28:01 +1000 (EST)
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Wed, 19 Aug 2009 12:28:15 +1000
From: "Manger, James H" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Wed, 19 Aug 2009 12:28:13 +1000
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Index: Acof/zu672ERb1kjTFGfum2I4fdDBQACOlKAABnofBA=
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

W1NhbnRvc2hdIE15IHN1Z2dlc3Rpb24gaXMgdGhhdCBpdCBpcyBhcHByb3ByaWF0ZSB0byB1c2Ug
dGhlIEFsZyBJRCBhbmQNCmFzc2VydCB0aGUgcGFyYW1ldGVycyBpbiBzcGl0ZSBvZiBSRkMgNTQ4
MC4gIE15IHJlYXNvbmluZyBpcyBhcyBmb2xsb3dzLg0KVGhlIEFTTi4xIHBlcm1pdHMgaXQ7IHdl
IG5lZWQgaXQgZm9yIGludGVyb3BlcmFiaWxpdHk7IHRoZSBSRkMgd2FudHMNCnRoZW0gYWJzZW50
IHdoZW4gYXNzZXJ0aW5nIGluIFNpZ25hdHVyZSBvciBTSUdORUQgTUFDUk8gc2luY2UgZ2V0dGlu
Zw0KdGhlIHBhcmFtZXRlcnMgZnJvbSB0aG9zZSBsb2NhdGlvbnMgaGF2ZSBwcm92ZW4gdG8gYmUg
dnVsbmVyYWJsZSB0bw0Kc3Vic3RpdHV0aW9uIGF0dGFjayAoYXQgbGVhc3QgaW4gZGVnZW5lcmF0
ZSBjYXNlcyk7IHRoZXkgZGVmaW5pdGVseSBhcmUNCm5vdCBhdXRoZW50aWNhdGVkLiAgQnV0LCB0
aGUgYXBwbGljYXRpb24gaW4gdGhpcyBJLUQgaXMgZGlmZmVyZW50Lg0KU2luY2UgdGhlIHdob2xl
IHN0cnVjdHVyZSBpcyB1bmF1dGhlbnRpY2F0ZWQsIHRoZXJlIGlzIG5vIGhhcm0gaW4NCnVuYXV0
aGVudGljYXRlZCBwYXJhbWV0ZXJzIGFzIHdlbGwuDQoNCg0KSSBkaXNhZ3JlZS4gVGhlIEFTTi4x
IERPRVMgTk9UIHN1cHBvcnQgdXNpbmcgdGhlIHNhbWUgb2JqZWN0IGlkIGluIGRpZmZlcmVudCBp
bnN0YW5jZXMgb2YgdGhlIEFsZ29yaXRobUlkZW50aWZpZXIgc3RydWN0dXJlIHdpdGggZGlmZmVy
ZW50IHBhcmFtZXRlciBzeW50YXhlcy4gVGhlIEFTTi4xIG1heSBhbGxvdyBBTlkgc3ludGF4IGZv
ciB0aGUgcGFyYW1ldGVycywgYnV0IHRoZSBhc3N1bXB0aW9uIChvciBleHBsaWNpdCBjb25zdHJh
aW50IC0tIGRlcGVuZGluZyBvbiB5b3VyIHZlcnNpb24gb2YgQVNOLjEpIGlzIHRoYXQgdGhlIHN5
bnRheCBpcyBkZWZpbmVkIGJ5IHRoZSBwcmVjZWRpbmcgb2JqZWN0IGlkLg0KDQpTb21lIGNvZGUg
d2lsbCBoYXZlIHRhYmxlcyBtYXBwaW5nIE9JRC10by1wYXJhbWV0ZXItc3ludGF4IHRvIGF1dG9t
YXRpY2FsbHkgZGVjb2RlIEFsZy5JZCB2YWx1ZXMuIFdpdGggU2FudG9zaCdzIHN1Z2dlc3Rpb24g
dGhlIGNvZGUgd291bGQgbmVlZCBkaWZmZXJlbnQgdGFibGVzIGRlcGVuZGluZyBvbiBjb250ZXh0
OiBvbmUgdGFibGUgd2hlbiBkZWNvZGluZyBhbiBBbGcuSWQgaW4gdGhlIFByZWZlcnJlZFNpZ25h
dHVyZUFsZ29yaXRobXMgdHlwZSwgYW5kIGFub3RoZXIgdGFibGUgd2hlbiBkZWNvZGluZyBhbiBB
bGcuSWQgaW4gYSBTaWduYXR1cmUgdHlwZS4gWXVjay4NCg0KDQpJdCBsb29rcyBsaWtlIHdoYXQg
aXMgcmVhbGx5IG5lZWRlZCBpcyBhIHJ1bGUgZm9yIG1hdGNoaW5nIGFjY2VwdGFibGUgY29tYmlu
YXRpb25zIG9mIHNpZ25hdHVyZSBhbGdvcml0aG0gYW5kIHNpZ25pbmcga2V5IHByb3BlcnRpZXMg
KGtleSBhbGdvcml0aG0gYW5kIGtleSBsZW5ndGgpLiBUbyBkbyB0aGF0IHByb3Blcmx5IHJlcXVp
cmVzIGEgbmV3IG1hdGNoaW5nIHJ1bGUgd2l0aCBpdHMgb3duIHN5bnRheC4NCg0KDQoNClAuUy4g
ZmllbGQgbmFtZXMgdXN1YWxseSAobXVzdD8pIHN0YXJ0IHdpdGggbG93ZXItY2FzZSBsZXR0ZXJz
IGluIEFTTi4xIHNvIFByZWZlcnJlZFNpZ25hdHVyZUFsZ29yaXRobXMgc2hvdWxkIGJlICJTRVFV
RU5DRSB7IGFsZ29yaXRobXMgU0VRVUVOQ0UgT0YgQWxnLklkLiB9Ii4NCg0KDQpKYW1lcyBNYW5n
ZXINCkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20NCklkZW50aXR5IGFuZCBzZWN1cml0
eSB0ZWFtIOKAlCBDaGllZiBUZWNobm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0K



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7IDn3NK079843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 06:49:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7IDn3CD079842; Tue, 18 Aug 2009 06:49:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7IDmpeW079822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Aug 2009 06:49:02 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id e41ba8a4.3185314736.45074.00-010.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Tue, 18 Aug 2009 07:49:02 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Tue, 18 Aug 2009 09:48:50 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
thread-index: Acof/zu672ERb1kjTFGfum2I4fdDBQACOlKA
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Sean Turner" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sean,

See responses below.=20

> -----Original Message-----
> From: Sean Turner [mailto:[e-mail]]=20
> Sent: Tuesday, August 18, 2009 8:27 AM
> To: Stefan Santesson
> Cc: Santosh Chokhani; [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>=20
> Stefan/Santosh,
>=20
> Jumping in mid-stream, but to fully specify what the client=20
> wants doesn't it need to specify the signing algorithm, the=20
> hashing algorithm,
>   algorithms parameters and the key size?  If we need all=20
> four of these then I'd suggest AlgorithmIdentifier might not=20
> be the right mechanism for unsigned requests.

[Santosh] Since this is public key (vice private key) operation and
since it is normally done in software, I do not think key size is
required.  Note that we generally do not define key size for public key
in certificates either.  It is implicit in the structure.

>=20
> I say unsigned requests because if the request is signed then=20
> you'd know the signing and hashing algorithm from the=20
> signature as well as the parameters and key size from the=20
> certificate.  None of the signing algorithm parameters I am=20
> aware of include key size.  Almost all are NULL.

[Santosh] Unless I do not read the I-D properly, this has nothing to do
with client signing requests.  It is a new request extension (and not a
request entry extension).  Request Vs request entry extension should be
clarified in the I-D (Seth also noted the ambiguity).

>=20
> If you still wanted to use algorithm identifier for unsigned,=20
> then for the ECDSA algs you'd need to assume that the=20
> recommendations in RFC 5480 are followed.  That is if you=20
> request ECDSA with no parameters in an algorithm identifier=20
> you know it's ECDSA, SHA-256, P-256, and 256-bit key.

[Santosh] The ecdsa-with-SHA256 does not mean P-256.  RFC 5480 itself
has two other curves that can be used with it.  There could be other
curves since the RFC does not restrict you.

[Santosh] My suggestion is that it is appropriate to use the Alg ID and
assert the parameters in spite of RFC 5480.  My reasoning is as follows.
The ASN.1 permits it; we need it for interoperability; the RFC wants
them absent when asserting in Signature or SIGNED MACRO since getting
the parameters from those locations have proven to be vulnerable to
substitution attack (at least in degenerate cases); they definitely are
not authenticated.  But, the application in this I-D is different.
Since the whole structure is unauthenticated, there is no harm in
unauthenticated parameters as well.=20

>=20
> I'm not sure how you infer the key size from=20
> sha256WithRSAEncryption or id-dsa-with-sha256?
>=20
> Maybe the way ahead is to include the clients cert in the request?
>=20
> spt
>=20
>=20
> Stefan Santesson wrote:
> > Where is it stated that parameters must be absent?
> > I tried to find it but failed.
> > It sounds strange as they are defined by the alg OID.
> >=20
> > Anyway, for clarity, I understand your position that you think the=20
> > defined
> > ASN.1 syntax is OK if we add a note saying that the client SHOULD=20
> > specify the curve. We could then also add text warning for the=20
> > consequences if the client does not specify the curve.
> >=20
> > Would that work?
> >=20
> > /Stefan
> >=20
> >=20
> > On 09-08-17 10:56 PM, "Santosh Chokhani"=20
> <[e-mail]> wrote:
> >=20
> >> Stefan,
> >>
> >> First of all: That is what I have been saying: "The client=20
> needs to=20
> >> specify the curve."
> >>
> >> But, when you go to 5480, the curves are specified for the=20
> Alg ID in=20
> >> SPKI.  If you look down at the ASN.1 for SIGNED MACRO type=20
> Alg ID, it=20
> >> says parameters are absent.  That is why note at the start of this=20
> >> thread on ocspagility-02 and I quote "If we have argument on=20
> >> populating these OIDs with parameters (e.g., based on RFC=20
> 5480), we=20
> >> may need to come up with different ASN.1."
> >>
> >>> -----Original Message-----
> >>> From: Stefan Santesson [mailto:[e-mail]]
> >>> Sent: Monday, August 17, 2009 4:47 PM
> >>> To: Santosh Chokhani
> >>> Cc: [e-mail]
> >>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>>
> >>> Santosch,
> >>>
> >>>
> >>> On 09-08-17 10:39 PM, "Santosh Chokhani"
> >>> <[e-mail]> wrote:
> >>>
> >>>> Stefan,
> >>>>
> >>>> Shall I assume that you will add a note on the type of Alg ID?
> >>>>
> >>> Yes, I can do that.
> >>>
> >>>> As to 5480, it has lot of curves in it.  If a client did
> >>> not ask for a
> >>>> curve and server used one of these curves, the client may not=20
> >>>> understand the curve and hence will not be able to process
> >>> the signature.
> >>>
> >>> But the client can specify curve, and in that case the=20
> server would=20
> >>> know what the client wants, right?. That feels good=20
> enough for me.=20
> >>> I'm not sure what more you would suggest that we do?
> >>>
> >>> /Stefan
> >>>
> >>>
> >>>
> >=20
> >=20
> >=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7ICRUmv074266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 05:27:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7ICRUoJ074265; Tue, 18 Aug 2009 05:27:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7ICRJee074254 for <[e-mail]>; Tue, 18 Aug 2009 05:27:29 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 98102 invoked from network); 18 Aug 2009 12:27:19 -0000
Received: from unknown (HELO thunderfish.local) (turners@71.191.10.134 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 18 Aug 2009 12:27:19 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: lkFoh7UVM1kScLqcJdjmf5KLEaecA3LO08tsZxOmgJURHodsF66GGlyoKnuaSU15XLtWFi6yJLhmqoeQIp_Wrs_3mhNxujMVGAmWB8Xo0sKMrN52wSdX66Q4cjx7ev9DRqczfdda6NFaHAF98JkfA8setHBlnw1jbaxg0nKklLr58OXl2sMoySq2ndGNnpswdkKt3hFJFLNfbD7I6cAdpvlRsBA7RrltjcnwjLGKN_8b9mGIr91tQeCP7YC2qDOjCOsbt6de42yMUGZxwm3u0MsLZtJKw0caR0tYihfWdk4HjxJzBnyaaHH1qWBIsoUgHb_FY33zPDI1f48oNfItZW1A5FGbeYf9EkQ-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Tue, 18 Aug 2009 08:27:18 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan/Santosh,

Jumping in mid-stream, but to fully specify what the client wants 
doesn't it need to specify the signing algorithm, the hashing algorithm, 
  algorithms parameters and the key size?  If we need all four of these 
then I'd suggest AlgorithmIdentifier might not be the right mechanism 
for unsigned requests.

I say unsigned requests because if the request is signed then you'd know 
the signing and hashing algorithm from the signature as well as the 
parameters and key size from the certificate.  None of the signing 
algorithm parameters I am aware of include key size.  Almost all are NULL.

If you still wanted to use algorithm identifier for unsigned, then for 
the ECDSA algs you'd need to assume that the recommendations in RFC 5480 
are followed.  That is if you request ECDSA with no parameters in an 
algorithm identifier you know it's ECDSA, SHA-256, P-256, and 256-bit key.

I'm not sure how you infer the key size from sha256WithRSAEncryption or 
id-dsa-with-sha256?

Maybe the way ahead is to include the clients cert in the request?

spt


Stefan Santesson wrote:
> Where is it stated that parameters must be absent?
> I tried to find it but failed.
> It sounds strange as they are defined by the alg OID.
> 
> Anyway, for clarity, I understand your position that you think the defined
> ASN.1 syntax is OK if we add a note saying that the client SHOULD specify
> the curve. We could then also add text warning for the consequences if the
> client does not specify the curve.
> 
> Would that work?
> 
> /Stefan
> 
> 
> On 09-08-17 10:56 PM, "Santosh Chokhani" <[e-mail]> wrote:
> 
>> Stefan,
>>
>> First of all: That is what I have been saying: "The client needs to
>> specify the curve."
>>
>> But, when you go to 5480, the curves are specified for the Alg ID in
>> SPKI.  If you look down at the ASN.1 for SIGNED MACRO type Alg ID, it
>> says parameters are absent.  That is why note at the start of this
>> thread on ocspagility-02 and I quote "If we have argument on populating
>> these OIDs with parameters (e.g., based on RFC 5480), we may need to
>> come up with different ASN.1."
>>
>>> -----Original Message-----
>>> From: Stefan Santesson [mailto:[e-mail]]
>>> Sent: Monday, August 17, 2009 4:47 PM
>>> To: Santosh Chokhani
>>> Cc: [e-mail]
>>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>>>
>>> Santosch,
>>>
>>>
>>> On 09-08-17 10:39 PM, "Santosh Chokhani"
>>> <[e-mail]> wrote:
>>>
>>>> Stefan,
>>>>
>>>> Shall I assume that you will add a note on the type of Alg ID?
>>>>
>>> Yes, I can do that.
>>>
>>>> As to 5480, it has lot of curves in it.  If a client did
>>> not ask for a 
>>>> curve and server used one of these curves, the client may not
>>>> understand the curve and hence will not be able to process
>>> the signature.
>>>
>>> But the client can specify curve, and in that case the server
>>> would know what the client wants, right?. That feels good
>>> enough for me. I'm not sure what more you would suggest that we do?
>>>
>>> /Stefan
>>>
>>>
>>>
> 
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HLN6eF020495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 14:23:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HLN6wT020494; Mon, 17 Aug 2009 14:23:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HLMxHP020482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 14:23:05 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 93ac98a4.3024870320.36030.00-011.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Mon, 17 Aug 2009 15:23:05 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Mon, 17 Aug 2009 17:22:58 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
thread-index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0QDcvToSAA7sInAACv4DhwAAm/QgAABVclcAADBQ8AAA2WAeAAAPApA=
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Yes.  It should work.

Below is a snippet from Page 16 of RFC 5480.  Note that we generally
recommend to not include parameters in Signature field or in SIGNED
MACRO (that is a topic for another discussion).  But, we may have found
a reason to use them (generic ASN.1 for Alg ID allows it) and in this
case it is useful since while MITM is possible, both client and server
know what they will do/accept.

 ecdsa-with-SHA1 OBJECT IDENTIFIER ::=3D {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }

   -- ECDSA with SHA-224
   -- Parameters are ABSENT

   ecdsa-with-SHA224 OBJECT IDENTIFIER ::=3D {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
     ecdsa-with-SHA2(3) 1 }

   -- ECDSA with SHA-256
   -- Parameters are ABSENT

   ecdsa-with-SHA256 OBJECT IDENTIFIER ::=3D {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
     ecdsa-with-SHA2(3) 2 }

   -- ECDSA with SHA-384
   -- Parameters are ABSENT
=20

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]=20
> Sent: Monday, August 17, 2009 5:16 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>=20
> Where is it stated that parameters must be absent?
> I tried to find it but failed.
> It sounds strange as they are defined by the alg OID.
>=20
> Anyway, for clarity, I understand your position that you=20
> think the defined
> ASN.1 syntax is OK if we add a note saying that the client=20
> SHOULD specify the curve. We could then also add text warning=20
> for the consequences if the client does not specify the curve.
>=20
> Would that work?
>=20
> /Stefan
>=20
>=20
> On 09-08-17 10:56 PM, "Santosh Chokhani"=20
> <[e-mail]> wrote:
>=20
> > Stefan,
> >=20
> > First of all: That is what I have been saying: "The client needs to=20
> > specify the curve."
> >=20
> > But, when you go to 5480, the curves are specified for the=20
> Alg ID in=20
> > SPKI.  If you look down at the ASN.1 for SIGNED MACRO type=20
> Alg ID, it=20
> > says parameters are absent.  That is why note at the start of this=20
> > thread on ocspagility-02 and I quote "If we have argument on=20
> > populating these OIDs with parameters (e.g., based on RFC 5480), we=20
> > may need to come up with different ASN.1."
> >=20
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[e-mail]]
> >> Sent: Monday, August 17, 2009 4:47 PM
> >> To: Santosh Chokhani
> >> Cc: [e-mail]
> >> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>=20
> >> Santosch,
> >>=20
> >>=20
> >> On 09-08-17 10:39 PM, "Santosh Chokhani"
> >> <[e-mail]> wrote:
> >>=20
> >>> Stefan,
> >>>=20
> >>> Shall I assume that you will add a note on the type of Alg ID?
> >>>=20
> >>=20
> >> Yes, I can do that.
> >>=20
> >>> As to 5480, it has lot of curves in it.  If a client did
> >> not ask for a
> >>> curve and server used one of these curves, the client may not=20
> >>> understand the curve and hence will not be able to process
> >> the signature.
> >>=20
> >> But the client can specify curve, and in that case the=20
> server would=20
> >> know what the client wants, right?. That feels good enough for me.=20
> >> I'm not sure what more you would suggest that we do?
> >>=20
> >> /Stefan
> >>=20
> >>=20
> >>=20
>=20
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HLGOlA020052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 14:16:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HLGO24020051; Mon, 17 Aug 2009 14:16:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HLGLbr020042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 14:16:23 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 68323 invoked from network); 17 Aug 2009 21:16:28 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 21:16:28 -0000
Received: (qmail 5904 invoked from network); 17 Aug 2009 21:16:20 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.7]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 21:16:20 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 17 Aug 2009 23:16:16 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>
CC: <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0QDcvToSAA7sInAACv4DhwAAm/QgAABVclcAADBQ8AAA2WAe
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Where is it stated that parameters must be absent?
I tried to find it but failed.
It sounds strange as they are defined by the alg OID.

Anyway, for clarity, I understand your position that you think the defined
ASN.1 syntax is OK if we add a note saying that the client SHOULD specify
the curve. We could then also add text warning for the consequences if the
client does not specify the curve.

Would that work?

/Stefan


On 09-08-17 10:56 PM, "Santosh Chokhani" <[e-mail]> wrote:

> Stefan,
> 
> First of all: That is what I have been saying: "The client needs to
> specify the curve."
> 
> But, when you go to 5480, the curves are specified for the Alg ID in
> SPKI.  If you look down at the ASN.1 for SIGNED MACRO type Alg ID, it
> says parameters are absent.  That is why note at the start of this
> thread on ocspagility-02 and I quote "If we have argument on populating
> these OIDs with parameters (e.g., based on RFC 5480), we may need to
> come up with different ASN.1."
> 
>> -----Original Message-----
>> From: Stefan Santesson [mailto:[e-mail]]
>> Sent: Monday, August 17, 2009 4:47 PM
>> To: Santosh Chokhani
>> Cc: [e-mail]
>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>> 
>> Santosch,
>> 
>> 
>> On 09-08-17 10:39 PM, "Santosh Chokhani"
>> <[e-mail]> wrote:
>> 
>>> Stefan,
>>> 
>>> Shall I assume that you will add a note on the type of Alg ID?
>>> 
>> 
>> Yes, I can do that.
>> 
>>> As to 5480, it has lot of curves in it.  If a client did
>> not ask for a 
>>> curve and server used one of these curves, the client may not
>>> understand the curve and hence will not be able to process
>> the signature.
>> 
>> But the client can specify curve, and in that case the server
>> would know what the client wants, right?. That feels good
>> enough for me. I'm not sure what more you would suggest that we do?
>> 
>> /Stefan
>> 
>> 
>> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKuVvu018652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 13:56:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HKuVPr018651; Mon, 17 Aug 2009 13:56:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKuTv2018645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 13:56:29 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id ef3c98a4.2012474288.868909.00-003.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Mon, 17 Aug 2009 14:56:30 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Mon, 17 Aug 2009 16:56:28 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
thread-index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0QDcvToSAA7sInAACv4DhwAAm/QgAABVclcAADBQ8A==
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

First of all: That is what I have been saying: "The client needs to
specify the curve."

But, when you go to 5480, the curves are specified for the Alg ID in
SPKI.  If you look down at the ASN.1 for SIGNED MACRO type Alg ID, it
says parameters are absent.  That is why note at the start of this
thread on ocspagility-02 and I quote "If we have argument on populating
these OIDs with parameters (e.g., based on RFC 5480), we may need to
come up with different ASN.1."

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]=20
> Sent: Monday, August 17, 2009 4:47 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>=20
> Santosch,
>=20
>=20
> On 09-08-17 10:39 PM, "Santosh Chokhani"=20
> <[e-mail]> wrote:
>=20
> > Stefan,
> >=20
> > Shall I assume that you will add a note on the type of Alg ID?
> >=20
>=20
> Yes, I can do that.
>=20
> > As to 5480, it has lot of curves in it.  If a client did=20
> not ask for a=20
> > curve and server used one of these curves, the client may not=20
> > understand the curve and hence will not be able to process=20
> the signature.
>=20
> But the client can specify curve, and in that case the server=20
> would know what the client wants, right?. That feels good=20
> enough for me. I'm not sure what more you would suggest that we do?
>=20
> /Stefan
>=20
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKoOkh018266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 13:50:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HKoOLH018265; Mon, 17 Aug 2009 13:50:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKoLR7018259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 13:50:23 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 91376 invoked from network); 17 Aug 2009 20:46:43 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 20:46:43 -0000
Received: (qmail 5224 invoked from network); 17 Aug 2009 20:46:34 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.7]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 20:46:34 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 17 Aug 2009 22:46:33 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>
CC: <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0QDcvToSAA7sInAACv4DhwAAm/QgAABVclc=
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosch,


On 09-08-17 10:39 PM, "Santosh Chokhani" <[e-mail]> wrote:

> Stefan,
> 
> Shall I assume that you will add a note on the type of Alg ID?
> 

Yes, I can do that.

> As to 5480, it has lot of curves in it.  If a client did not ask for a
> curve and server used one of these curves, the client may not understand
> the curve and hence will not be able to process the signature.

But the client can specify curve, and in that case the server would know
what the client wants, right?. That feels good enough for me. I'm not sure
what more you would suggest that we do?

/Stefan




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKdc5M017749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 13:39:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HKdcFA017748; Mon, 17 Aug 2009 13:39:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKdaS2017742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 13:39:37 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 900c98a4.1878256560.5521.00-011.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Mon, 17 Aug 2009 14:39:37 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Mon, 17 Aug 2009 16:39:36 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
thread-index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0QDcvToSAA7sInAACv4DhwAAm/Qg
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Shall I assume that you will add a note on the type of Alg ID?

As to 5480, it has lot of curves in it.  If a client did not ask for a
curve and server used one of these curves, the client may not understand
the curve and hence will not be able to process the signature.

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]=20
> Sent: Monday, August 17, 2009 4:20 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>=20
> Santosch,
>=20
> I will change encryption to Signing.
>=20
> As to the rest I may miss what you are saying.
> I do agree that the algorithm identifier specified must be=20
> signature algorithms (specifying both hash and signing algorithm).
>=20
> With respect to ECC I'm not sure what you are missing.
> I was under the impression that RFC5480 is adequate for=20
> providing interoperability. RFC 5480 is compatible with the=20
> specified syntax. What else do we need?
>=20
> /Stefan
>=20
> On 09-08-17 9:55 PM, "Santosh Chokhani"=20
> <[e-mail]> wrote:
>=20
> > Stefan,
> >=20
> > See responses in-line.
> >=20
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[e-mail]]
> >> Sent: Monday, August 17, 2009 3:58 AM
> >> To: Santosh Chokhani
> >> Cc: [e-mail]
> >> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>=20
> >> Santosch,
> >>=20
> >> Thanks for the clarifications. Comments in line.
> >>=20
> >>=20
> >> On 09-08-13 12:37 AM, "Santosh Chokhani"
> >> <[e-mail]> wrote:
> >>=20
> >>>=20
> >>> Stefan,
> >>>=20
> >>> Thanks for addressing most of my concerns.  I have two partial=20
> >>> concerns remaining from old comments.  I have also=20
> recommended text=20
> >>> for two questions you had, but would like folks who specify
> >> Algorithm
> >>> Identifier
> >>> ASN.1 to make sure they are ok with it.
> >>>=20
> >>> There are no new comments below.
> >>>=20
> >>> COMMENT 1
> >>> Section 2 states:
> >>>=20
> >>>    "o  An implementation may intentionally wish to guard=20
> against the
> >>>       possibility of a compromise resulting from a
> >> signature algorithm
> >>>       compromise by employing two separate encryption algorithms."
> >>>=20
> >>> This should be changed as follows:
> >>>      =20
> >>>    "o  A PKI may wish to guard against the possibility of a
> >> compromise
> >>> resulting from a signature algorithm compromise by employing two=20
> >>> separate signature algorithms for CRL and OCSP signing,
> >> thus allowing
> >>> the relying parties to employ one mechanism or other for
> >> certificate
> >>> status validation."
> >>>=20
> >>=20
> >> I have to disagree to this change. Your text may be=20
> correct in many=20
> >> situations but I don't feel that it is meaningful for this draft.=20
> >> This is just orientation text and the one that is=20
> currently present=20
> >> is IMO more generic and accurate.
> >=20
> > [Santosh] OK.  I am fine with your statement.  Can you change=20
> > "encryption" to "signature".
> >=20
> >>=20
> >>=20
> >>> COMMENT 2
> >>> Section 3, The Algorithm Identifier should be one asserted
> >> in SIGNED
> >>> MACRO or Signature field in order to cover hashing algorithms.
> >>>=20
> >>=20
> >> I think it is adequate to refer to the structure of section
> >> 4.1.1.2 of RFC 5280. I have added a reference.
> >=20
> > [Santosh] This is problematic in light of ongoing hash algorithms=20
> > discussion.  If public key algorithm asserted in SPKI is=20
> used, it will=20
> > not convey hashing algorithm.  As I recall, on the previous=20
> go around,=20
> > you asked for my advise.  Upon reflection, I think it needs=20
> to be the=20
> > one that conveys the hashing and signing algorithm.
> >=20
> >>=20
> >>> COMMENT 3
> >>> Section 3, Unlike SIGNED MACRO and Signature field, the Algorithm=20
> >>> Identifier can contain parameters for the client to declare its=20
> >>> constraints.  For example, a client who only processes
> >> Suite B curves
> >>> only may do so by using the following ASN.1 structure:
> >>>=20
> >>> SEQUENCE {
> >>> SEQUENCE {ecdsa-with-SHA256 OBJECT IDENTIFIER
> >>>    secp256r1 OBJECT IDENTIFIER}
> >>> SEQUENCE {ecdsa-with-SHA384 OBJECT IDENTIFIER
> >>>    secp384r1 OBJECT IDENTIFIER}
> >>>    }
> >>>=20
> >>> If we have argument on populating these OIDs with=20
> parameters (e.g.,=20
> >>> based on RFC 5480), we may need to come up with different ASN.1.
> >>>=20
> >>=20
> >> The definition of AlgorithmIdentifier in RFC 5280 which is=20
> consistent=20
> >> with the X.509 SIGNED macro includes parameter:
> >>=20
> >>    AlgorithmIdentifier  ::=3D  SEQUENCE  {
> >>         algorithm               OBJECT IDENTIFIER,
> >>         parameters              ANY DEFINED BY algorithm=20
> OPTIONAL  }
> >>=20
> >> Is this not enough?
> >=20
> > [Santosh] If we are concerned with algorithm agility and=20
> > interoperability, if an implementation does not recognize a=20
> EC curve=20
> > OID, we will not achieve the objective.  Here also you requested my=20
> > input.  But, more importantly, as we move to EC, named curves=20
> > recognized by the client do become an issue of interoperability.
> >=20
> >>=20
> >>=20
> >>> COMMENT 4
> >>> Section 7.2 should be revised to reference LTANS DSSC I-D=20
> to shield=20
> >>> the client against weak algorithms.  It is desirable that IETF=20
> >>> standards build on each other.
> >>>=20
> >>=20
> >> First I want to avoid referencing an I-D and secondly I'm not=20
> >> convinced that it is motivated in the context of this draft.
> >=20
> > [Santosh  am ok with your decision. I am pointing this out=20
> since this=20
> > is the only effort I know in IETF where an implementation can guard=20
> > against invoking weak algorithm which may still be embedded in the=20
> > implementation.
> >=20
> >>=20
> >> /Stefan
> >>=20
> >>=20
> >>>=20
> >>> Santosh Chokhani
> >>> CygnaCom Solutions
> >>>=20
> >>=20
> >>=20
> >>=20
>=20
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKJhaP016632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 13:19:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HKJhfv016631; Mon, 17 Aug 2009 13:19:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HKJZSw016620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 13:19:42 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 84063 invoked from network); 17 Aug 2009 20:19:42 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 20:19:42 -0000
Received: (qmail 10754 invoked from network); 17 Aug 2009 20:19:33 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.7]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 20:19:33 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 17 Aug 2009 22:19:33 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>
CC: <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0QDcvToSAA7sInAACv4Dhw==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosch,

I will change encryption to Signing.

As to the rest I may miss what you are saying.
I do agree that the algorithm identifier specified must be signature
algorithms (specifying both hash and signing algorithm).

With respect to ECC I'm not sure what you are missing.
I was under the impression that RFC5480 is adequate for providing
interoperability. RFC 5480 is compatible with the specified syntax. What
else do we need?

/Stefan

On 09-08-17 9:55 PM, "Santosh Chokhani" <[e-mail]> wrote:

> Stefan,
> 
> See responses in-line.
> 
>> -----Original Message-----
>> From: Stefan Santesson [mailto:[e-mail]]
>> Sent: Monday, August 17, 2009 3:58 AM
>> To: Santosh Chokhani
>> Cc: [e-mail]
>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>> 
>> Santosch,
>> 
>> Thanks for the clarifications. Comments in line.
>> 
>> 
>> On 09-08-13 12:37 AM, "Santosh Chokhani"
>> <[e-mail]> wrote:
>> 
>>> 
>>> Stefan,
>>> 
>>> Thanks for addressing most of my concerns.  I have two partial
>>> concerns remaining from old comments.  I have also recommended text
>>> for two questions you had, but would like folks who specify
>> Algorithm 
>>> Identifier
>>> ASN.1 to make sure they are ok with it.
>>> 
>>> There are no new comments below.
>>> 
>>> COMMENT 1
>>> Section 2 states:
>>> 
>>>    "o  An implementation may intentionally wish to guard against the
>>>       possibility of a compromise resulting from a
>> signature algorithm
>>>       compromise by employing two separate encryption algorithms."
>>> 
>>> This should be changed as follows:
>>>       
>>>    "o  A PKI may wish to guard against the possibility of a
>> compromise 
>>> resulting from a signature algorithm compromise by employing two
>>> separate signature algorithms for CRL and OCSP signing,
>> thus allowing 
>>> the relying parties to employ one mechanism or other for
>> certificate 
>>> status validation."
>>> 
>> 
>> I have to disagree to this change. Your text may be correct
>> in many situations but I don't feel that it is meaningful for
>> this draft. This is just orientation text and the one that is
>> currently present is IMO more generic and accurate.
> 
> [Santosh] OK.  I am fine with your statement.  Can you change
> "encryption" to "signature".
> 
>> 
>> 
>>> COMMENT 2
>>> Section 3, The Algorithm Identifier should be one asserted
>> in SIGNED 
>>> MACRO or Signature field in order to cover hashing algorithms.
>>> 
>> 
>> I think it is adequate to refer to the structure of section
>> 4.1.1.2 of RFC 5280. I have added a reference.
> 
> [Santosh] This is problematic in light of ongoing hash algorithms
> discussion.  If public key algorithm asserted in SPKI is used, it will
> not convey hashing algorithm.  As I recall, on the previous go around,
> you asked for my advise.  Upon reflection, I think it needs to be the
> one that conveys the hashing and signing algorithm.
> 
>> 
>>> COMMENT 3
>>> Section 3, Unlike SIGNED MACRO and Signature field, the Algorithm
>>> Identifier can contain parameters for the client to declare its
>>> constraints.  For example, a client who only processes
>> Suite B curves 
>>> only may do so by using the following ASN.1 structure:
>>> 
>>> SEQUENCE {
>>> SEQUENCE {ecdsa-with-SHA256 OBJECT IDENTIFIER
>>>    secp256r1 OBJECT IDENTIFIER}
>>> SEQUENCE {ecdsa-with-SHA384 OBJECT IDENTIFIER
>>>    secp384r1 OBJECT IDENTIFIER}
>>>    }
>>> 
>>> If we have argument on populating these OIDs with parameters (e.g.,
>>> based on RFC 5480), we may need to come up with different ASN.1.
>>> 
>> 
>> The definition of AlgorithmIdentifier in RFC 5280 which is
>> consistent with the X.509 SIGNED macro includes parameter:
>> 
>>    AlgorithmIdentifier  ::=  SEQUENCE  {
>>         algorithm               OBJECT IDENTIFIER,
>>         parameters              ANY DEFINED BY algorithm OPTIONAL  }
>> 
>> Is this not enough?
> 
> [Santosh] If we are concerned with algorithm agility and
> interoperability, if an implementation does not recognize a EC curve
> OID, we will not achieve the objective.  Here also you requested my
> input.  But, more importantly, as we move to EC, named curves recognized
> by the client do become an issue of interoperability.
> 
>> 
>> 
>>> COMMENT 4
>>> Section 7.2 should be revised to reference LTANS DSSC I-D to shield
>>> the client against weak algorithms.  It is desirable that IETF
>>> standards build on each other.
>>> 
>> 
>> First I want to avoid referencing an I-D and secondly I'm not
>> convinced that it is motivated in the context of this draft.
> 
> [Santosh  am ok with your decision. I am pointing this out since this is
> the only effort I know in IETF where an implementation can guard against
> invoking weak algorithm which may still be embedded in the
> implementation.
> 
>> 
>> /Stefan
>> 
>> 
>>> 
>>> Santosh Chokhani
>>> CygnaCom Solutions
>>> 
>> 
>> 
>> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HJtlEt015047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 12:55:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HJtlOj015046; Mon, 17 Aug 2009 12:55:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HJtK0v015031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 12:55:28 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 1b5b98a4.2128411568.252806.00-013.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Mon, 17 Aug 2009 13:55:29 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Mon, 17 Aug 2009 15:55:16 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
thread-index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0QDcvToSAA7sInA=
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

See responses in-line.=20

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]=20
> Sent: Monday, August 17, 2009 3:58 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>=20
> Santosch,
>=20
> Thanks for the clarifications. Comments in line.
>=20
>=20
> On 09-08-13 12:37 AM, "Santosh Chokhani"=20
> <[e-mail]> wrote:
>=20
> >=20
> > Stefan,
> >=20
> > Thanks for addressing most of my concerns.  I have two partial=20
> > concerns remaining from old comments.  I have also recommended text=20
> > for two questions you had, but would like folks who specify=20
> Algorithm=20
> > Identifier
> > ASN.1 to make sure they are ok with it.
> >=20
> > There are no new comments below.
> >=20
> > COMMENT 1
> > Section 2 states:
> >=20
> >    "o  An implementation may intentionally wish to guard against the
> >       possibility of a compromise resulting from a=20
> signature algorithm
> >       compromise by employing two separate encryption algorithms."
> >=20
> > This should be changed as follows:
> >      =20
> >    "o  A PKI may wish to guard against the possibility of a=20
> compromise=20
> > resulting from a signature algorithm compromise by employing two=20
> > separate signature algorithms for CRL and OCSP signing,=20
> thus allowing=20
> > the relying parties to employ one mechanism or other for=20
> certificate=20
> > status validation."
> >=20
>=20
> I have to disagree to this change. Your text may be correct=20
> in many situations but I don't feel that it is meaningful for=20
> this draft. This is just orientation text and the one that is=20
> currently present is IMO more generic and accurate.

[Santosh] OK.  I am fine with your statement.  Can you change
"encryption" to "signature".

>=20
>=20
> > COMMENT 2
> > Section 3, The Algorithm Identifier should be one asserted=20
> in SIGNED=20
> > MACRO or Signature field in order to cover hashing algorithms.
> >=20
>=20
> I think it is adequate to refer to the structure of section=20
> 4.1.1.2 of RFC 5280. I have added a reference.

[Santosh] This is problematic in light of ongoing hash algorithms
discussion.  If public key algorithm asserted in SPKI is used, it will
not convey hashing algorithm.  As I recall, on the previous go around,
you asked for my advise.  Upon reflection, I think it needs to be the
one that conveys the hashing and signing algorithm.

>=20
> > COMMENT 3
> > Section 3, Unlike SIGNED MACRO and Signature field, the Algorithm=20
> > Identifier can contain parameters for the client to declare its=20
> > constraints.  For example, a client who only processes=20
> Suite B curves=20
> > only may do so by using the following ASN.1 structure:
> >=20
> > SEQUENCE {
> > SEQUENCE {ecdsa-with-SHA256 OBJECT IDENTIFIER
> >    secp256r1 OBJECT IDENTIFIER}
> > SEQUENCE {ecdsa-with-SHA384 OBJECT IDENTIFIER
> >    secp384r1 OBJECT IDENTIFIER}
> >    }
> >=20
> > If we have argument on populating these OIDs with parameters (e.g.,=20
> > based on RFC 5480), we may need to come up with different ASN.1.
> >=20
>=20
> The definition of AlgorithmIdentifier in RFC 5280 which is=20
> consistent with the X.509 SIGNED macro includes parameter:
>=20
>    AlgorithmIdentifier  ::=3D  SEQUENCE  {
>         algorithm               OBJECT IDENTIFIER,
>         parameters              ANY DEFINED BY algorithm OPTIONAL  }
>=20
> Is this not enough?

[Santosh] If we are concerned with algorithm agility and
interoperability, if an implementation does not recognize a EC curve
OID, we will not achieve the objective.  Here also you requested my
input.  But, more importantly, as we move to EC, named curves recognized
by the client do become an issue of interoperability.

>=20
>=20
> > COMMENT 4
> > Section 7.2 should be revised to reference LTANS DSSC I-D to shield=20
> > the client against weak algorithms.  It is desirable that IETF=20
> > standards build on each other.
> >=20
>=20
> First I want to avoid referencing an I-D and secondly I'm not=20
> convinced that it is motivated in the context of this draft.

[Santosh  am ok with your decision. I am pointing this out since this is
the only effort I know in IETF where an implementation can guard against
invoking weak algorithm which may still be embedded in the
implementation.

>=20
> /Stefan
>=20
>=20
> >=20
> > Santosh Chokhani
> > CygnaCom Solutions
> >=20
>=20
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7H7vdXS081947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 00:57:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7H7vdoH081946; Mon, 17 Aug 2009 00:57:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7H7vauZ081938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Aug 2009 00:57:37 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 43464 invoked from network); 17 Aug 2009 07:57:37 -0000
Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 07:57:37 -0000
Received: (qmail 27377 invoked from network); 17 Aug 2009 07:57:34 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.7]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 07:57:34 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 17 Aug 2009 09:57:32 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>
CC: <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0QDcvToS
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosch,

Thanks for the clarifications. Comments in line.


On 09-08-13 12:37 AM, "Santosh Chokhani" <[e-mail]> wrote:

> 
> Stefan,
> 
> Thanks for addressing most of my concerns.  I have two partial concerns
> remaining from old comments.  I have also recommended text for two
> questions you had, but would like folks who specify Algorithm Identifier
> ASN.1 to make sure they are ok with it.
> 
> There are no new comments below.
> 
> COMMENT 1
> Section 2 states:
> 
>    "o  An implementation may intentionally wish to guard against the
>       possibility of a compromise resulting from a signature algorithm
>       compromise by employing two separate encryption algorithms."
> 
> This should be changed as follows:
>       
>    "o  A PKI may wish to guard against the possibility of a compromise
> resulting from a signature algorithm compromise by employing two
> separate signature algorithms for CRL and OCSP signing, thus allowing
> the relying parties to employ one mechanism or other for certificate
> status validation."
> 

I have to disagree to this change. Your text may be correct in many
situations but I don't feel that it is meaningful for this draft. This is
just orientation text and the one that is currently present is IMO more
generic and accurate.


> COMMENT 2
> Section 3, The Algorithm Identifier should be one asserted in SIGNED
> MACRO or Signature field in order to cover hashing algorithms.
> 

I think it is adequate to refer to the structure of section 4.1.1.2 of RFC
5280. I have added a reference.

> COMMENT 3
> Section 3, Unlike SIGNED MACRO and Signature field, the Algorithm
> Identifier can contain parameters for the client to declare its
> constraints.  For example, a client who only processes Suite B curves
> only may do so by using the following ASN.1 structure:
> 
> SEQUENCE {
> SEQUENCE {ecdsa-with-SHA256 OBJECT IDENTIFIER
>    secp256r1 OBJECT IDENTIFIER}
> SEQUENCE {ecdsa-with-SHA384 OBJECT IDENTIFIER
>    secp384r1 OBJECT IDENTIFIER}
>    }
> 
> If we have argument on populating these OIDs with parameters (e.g.,
> based on RFC 5480), we may need to come up with different ASN.1.
> 

The definition of AlgorithmIdentifier in RFC 5280 which is consistent with
the X.509 SIGNED macro includes parameter:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

Is this not enough?


> COMMENT 4
> Section 7.2 should be revised to reference LTANS DSSC I-D to shield the
> client against weak algorithms.  It is desirable that IETF standards
> build on each other.
> 

First I want to avoid referencing an I-D and secondly I'm not convinced that
it is motivated in the context of this draft.

/Stefan


> 
> Santosh Chokhani
> CygnaCom Solutions
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7H6rZfJ078436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 23:53:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7H6rZOu078435; Sun, 16 Aug 2009 23:53:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7H6rWMl078429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 16 Aug 2009 23:53:34 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 70874 invoked from network); 17 Aug 2009 06:53:33 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 06:53:33 -0000
Received: (qmail 36091 invoked from network); 17 Aug 2009 06:53:31 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.7]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 06:53:31 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 17 Aug 2009 08:53:29 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt
From: Stefan Santesson <[e-mail]>
To: Seth Hitchings <[e-mail]>, Santosh Chokhani <[e-mail]>, ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Thread-Index: AcoZ1DbkFeo2XmhRRhq2Obxb6zRS1QBeXHLPAGfFgNAAhqueQA==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Seth. Good catches both of them.

Comments in line.


On 09-08-14 4:47 PM, "Seth Hitchings" <[e-mail]> wrote:

> 
> Hi Stefan,
> 
> I have two reasonably straightforward comments.
> 
> 1. Section 3 defines an OCSP request extension, but neglects to specify
> which of the two extension lists (requestExtensions or
> singleRequestExtensions) the extension should be included in.
> 

As this is a declaration of the general preference of the client It must be
included in requestExtensions.

I'll add a note.

> 2. Section 4.1, item 3 refers to the "signing algorithm used to sign the
> CertID specified in the query", however, the CertID is not signed. Is
> this meant to specify that the server use the signing algorithm used by
> the client to sign the entire OCSPRequest, or to specify that the server
> use the signing algorithm used by the CA to sign the certificate
> identified by the CertID? If the answer is the latter, what is the
> expected behavior if the request queries multiple certificates that were
> signed using different signature algorithms?
> 

It's meant to specify the signing algorithm used to sign the request if the
request is signed.

> Thanks,
> Seth Hitchings
> CoreStreet, Ltd.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7H6AZLY076723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 23:10:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7H6AZBh076722; Sun, 16 Aug 2009 23:10:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7H6AWYZ076713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 16 Aug 2009 23:10:34 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 80155 invoked from network); 17 Aug 2009 06:10:31 -0000
Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 06:10:31 -0000
Received: (qmail 19941 invoked from network); 17 Aug 2009 06:10:29 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.7]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 17 Aug 2009 06:10:29 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 17 Aug 2009 08:10:27 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[e-mail]>
To: Sean Turner <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Thread-Index: AcofAWopKW7+fqLaZkWkRnM7aCEL9g==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In line;


On 09-08-16 3:58 PM, "Sean Turner" <[e-mail]> wrote:

> 
> Is this ID intended to be an update of RFC 2560?  If so, then it should
> indicate as much on the 1st page's header.
> 

Yes it should, I'll add.

> Shouldn't this be standards track and not informational track
> (http://www.ietf.org/proceedings/73/minutes/pkix.htm)?
> 
I think that is also correct. I'll update unless I hear objections.

> Sec 3: In the para after the ASN.1 snippet, I think we should add "The
> object identifiers (OIDs) are listed in order of their preference" or
> something similar.
> 

Good suggestion

> Sec 4.1 bullet #5 makes me ask if the required algorithms in this
> version of OCSP (RFC 2560) are DSA/RSA (must/should) with SHA-1 (must),
> then are responses signed with RSA and SHA-256 considered non-compliant
> with RFC 2560? 

No, I can't see that the draft claims this, or that we would like to say
this. First of all, this list is optional (Given by the first sentence of
4.1)

> Also, the requirements in Sec 4.3 of RFC 2560 are for
> the client with the exception of SHA-1 so it seems like there might be a
> disconnect because there is no explicit server musts use X algorithm.
> 
Well, the server would naturally select one algorithm that is supported by
the clients.

But with respect to the OCSP agility document, maybe could improve the
guidelines if we say the following instead:

   5.  Using a mandatory or recommended signing algorithm specified for
       the version of the OCSP protocol in use.


/Stefan




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7GDwC6u031194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 06:58:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7GDwC0g031193; Sun, 16 Aug 2009 06:58:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7GDw6aJ031187 for <[e-mail]>; Sun, 16 Aug 2009 06:58:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 95939 invoked from network); 16 Aug 2009 13:58:06 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.241.10.248 with plain) by smtp101.biz.mail.re2.yahoo.com with SMTP; 16 Aug 2009 13:58:04 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Sun, 16 Aug 2009 09:58:00 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is this ID intended to be an update of RFC 2560?  If so, then it should
indicate as much on the 1st page's header.

Shouldn't this be standards track and not informational track
(http://www.ietf.org/proceedings/73/minutes/pkix.htm)?

Sec 3: In the para after the ASN.1 snippet, I think we should add "The
object identifiers (OIDs) are listed in order of their preference" or
something similar.

Sec 4.1 bullet #5 makes me ask if the required algorithms in this
version of OCSP (RFC 2560) are DSA/RSA (must/should) with SHA-1 (must),
then are responses signed with RSA and SHA-256 considered non-compliant
with RFC 2560?  Also, the requirements in Sec 4.3 of RFC 2560 are for 
the client with the exception of SHA-1 so it seems like there might be a 
disconnect because there is no explicit server musts use X algorithm.

spt




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7G8DQWo016191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 01:13:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7G8DQQh016190; Sun, 16 Aug 2009 01:13:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7G8DJbw016179 for <[e-mail]>; Sun, 16 Aug 2009 01:13:25 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.140.3) (authenticated as u18116613) id 4A5BC8BE00293612 for [e-mail]; Sun, 16 Aug 2009 10:13:19 +0200
Message-ID: <ADFA09505E12436E9474E9BFCE0C3EC0@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: PKI support in W3C's HTML5
Date: Sun, 16 Aug 2009 10:13:57 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0096_01CA1E5A.4490A320"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0096_01CA1E5A.4490A320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, I know that PKIX is only targeting ASN.1-based stuff related to =
PKI.  However, there may be a few PKIX subscribers out there who have =
interests in things that affect the use of these ASN.1 structures as =
well :-)

W3C has recently adopted WHATWG's HTML5 work which in addition to =
extended content support also incorporates Netscape's <keygen> in the =
plot.

I have since long time back claimed that <keygen> is insufficient since =
it doesn't enable issuers to define:

- anything related to PIN-codes
- anything related to key-strength (it is unilaterally set by the user)

In addition, there is no "algorithm agility" support.

Apparently Microsoft also have doubts about the viability of <keygen>:
http://lists.w3.org/Archives/Public/public-html/2009Aug/0389.html

Is a "<keygen>" facility important?  For PCs probably not (smart cards =
are distributed physically), but for mobile phones there is hardly any =
alternative since SIM-cards are constrained by operators, while $200+ =
external card readers probably don't fit on-line banking and similar =
consumer activities:
http://na.blackberry.com/eng/ataglance/security/products/smartcardreader
SD-cards is another possibility but are much more complex to get running =
than schemes based on on-bard storage of credentials because form =
factors vary and there is still no generally accepted interface between =
PKI-cards and operating systems making interoperability a true nightmare =
not to mention the distribution of third-party middleware to consumers.

So what's missing?  A "<keygen>" addressing everything from ease-of-use =
to algorithm agility, as well as supporting security-enhancing additions =
to CPUs like TI's "TrustZone" and Intel's "TXT".

Where would such scheme be defined?  It appears that there are no =
standards bodies catering for "neutral" mobile phone security solutions; =
they are usually biased towards mobile phone operators, largely ignoring =
the obvious:

 "On the Internet anybody can be an operator of something"

Standards (de-facto or real), should of course be designed accordingly.

Note: For enterprises there are as shown some [quite pricy] solutions =
supporting a limited set of platforms; what I'm referring to are the =
more than 3 BILLION consumers equipped with mobile phones.  Since the =
mobile phone is quickly becoming our closest link to the Internet, this =
is a pretty interesting area.

The primary hurdle seems to be that in order to succeed, you must go =
outside of traditional standardization boundaries since it is not about =
creating "yet another protocol", it is about providing a complete =
issuer-independent foundation for distributing and managing user-keys,  =
which also runs deep into cryptographic platforms which were never =
designed for secure remote operations by consumers neither having =
"Security Officers" nor IT-support at hand!

Thanx,
Anders Rundgren
------=_NextPart_000_0096_01CA1E5A.4490A320
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18813">
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT size=3D2 face=3DArial>Yes, I know that PKIX is only targeting =
ASN.1-based=20
stuff related to PKI. &nbsp;However, there may be a few PKIX subscribers =
out=20
there who have interests in things that affect the use of these ASN.1 =
structures=20
as well :-)<BR><BR>W3C has recently adopted WHATWG's HTML5 work which in =

addition to extended content support also incorporates Netscape's =
&lt;keygen&gt;=20
in the plot.<BR><BR>I have since long time back claimed that =
&lt;keygen&gt; is=20
insufficient since it doesn't enable issuers to define:<BR><BR>- =
anything=20
related to PIN-codes<BR>- anything related to key-strength (it is =
unilaterally=20
set by the user)<BR><BR>In addition, there is no "algorithm agility"=20
support.<BR><BR>Apparently Microsoft also have doubts about the =
viability of=20
&lt;keygen&gt;:<BR></FONT><A=20
href=3D"http://lists.w3.org/Archives/Public/public-html/2009Aug/0389.html=
"><FONT=20
size=3D2=20
face=3DArial>http://lists.w3.org/Archives/Public/public-html/2009Aug/0389=
.html</FONT></A><BR><BR><FONT=20
size=3D2 face=3DArial>Is a "&lt;keygen&gt;" facility important?&nbsp; =
For PCs=20
probably not (smart cards are distributed <EM>physically</EM>), but for =
mobile=20
phones there is hardly any alternative since SIM-cards are constrained =
by=20
operators, while $200+ external card readers probably don't fit on-line =
banking=20
and similar consumer activities:<BR></FONT><A=20
href=3D"http://na.blackberry.com/eng/ataglance/security/products/smartcar=
dreader"><FONT=20
size=3D2=20
face=3DArial>http://na.blackberry.com/eng/ataglance/security/products/sma=
rtcardreader</FONT></A><BR><FONT=20
size=3D2 face=3DArial>SD-cards is another possibility but are much more =
complex to=20
get running than schemes based on on-bard storage of credentials because =
form=20
factors vary and there is still no generally accepted interface between=20
PKI-cards and operating systems making interoperability a true nightmare =
not to=20
mention the distribution of third-party middleware to =
consumers.<BR><BR>So=20
what's missing?&nbsp; A "&lt;keygen&gt;" addressing everything from =
ease-of-use=20
to algorithm agility, as well as supporting security-enhancing additions =
to CPUs=20
</FONT><FONT size=3D2 face=3DArial>like TI's "TrustZone" and Intel's=20
"TXT".<BR><BR>Where would such scheme be defined?&nbsp; It appears that =
there=20
are no standards bodies catering for "neutral" mobile phone security =
solutions;=20
they are usually biased towards mobile phone operators, largely ignoring =
the=20
obvious:<BR><BR><EM>&nbsp;"On the Internet anybody can be an operator of =

something"<BR></EM><BR>Standards (de-facto or real), should of course be =

designed accordingly.<BR><BR>Note: For enterprises there are as shown =
some=20
[quite pricy] solutions </FONT><FONT size=3D2 face=3DArial>supporting a =
limited set=20
of platforms; what I'm referring to are the more than </FONT><FONT =
size=3D2=20
face=3DArial>3 BILLION consumers equipped with mobile phones.&nbsp; =
Since the=20
mobile phone </FONT><FONT size=3D2 face=3DArial>is quickly =
becoming&nbsp;our closest=20
link to the Internet, this is a&nbsp;pretty interesting =
area.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2 face=3DArial>The primary hurdle seems to be that in =
order to=20
succeed, you must go </FONT><FONT size=3D2 face=3DArial>outside of =
traditional=20
standardization boundaries since it is not about creating </FONT><FONT =
size=3D2=20
face=3DArial>"yet another protocol", it is about providing =
a&nbsp;complete=20
<EM>issuer-independent </EM></FONT><FONT size=3D2 =
face=3DArial><EM>foundation for=20
distributing and managing user-keys</EM>,&nbsp; which also runs deep =
into=20
</FONT><FONT size=3D2 face=3DArial>cryptographic platforms which were =
never designed=20
for secure remote operations </FONT><FONT size=3D2 face=3DArial>by =
consumers neither=20
having "Security Officers" nor IT-support at hand!</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2 face=3DArial>Thanx,<BR>Anders=20
Rundgren</FONT></DIV></BODY></HTML>

------=_NextPart_000_0096_01CA1E5A.4490A320--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7FKBv2t086072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Aug 2009 13:11:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7FKBvGK086071; Sat, 15 Aug 2009 13:11:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7FKBtDv086057 for <[e-mail]>; Sat, 15 Aug 2009 13:11:56 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.2]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1McOfP-0004dH-DK; Sat, 15 Aug 2009 15:11:51 -0400
Mime-Version: 1.0
Message-Id: <p06240814c6acbe4b7a7b@[192.168.1.2]>
In-Reply-To: <p06240826c6a7c0081700@[10.20.30.158]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p06240806c6a7a6c8f9e2@[10.84.131.96]> <p06240826c6a7c0081700@[10.20.30.158]>
Date: Sat, 15 Aug 2009 15:34:54 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>At 6:54 PM -0400 8/11/09, Stephen Kent wrote:
>>Since the 08 version has been posted and it addressed all of Sean's comments,
>>I think it is time to initiate WGLC.  It starts tomorrow (8/12) and 
>>will end on 8/26.
>
>Just to be clear: this is a *second* WGLC, or WGSLC, if you will.
>
>--Paul Hoffman, Director
>--VPN Consortium

yes.

That is correct.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7EElIr1096159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 07:47:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7EElIe3096158; Fri, 14 Aug 2009 07:47:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [216.41.58.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7EEl8uJ096138 for <[e-mail]>; Fri, 14 Aug 2009 07:47:17 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Date: Fri, 14 Aug 2009 10:47:05 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Thread-Index: AcoZ1DbkFeo2XmhRRhq2Obxb6zRS1QBeXHLPAGfFgNA=
References: <[e-mail]> <[e-mail]>
From: "Seth Hitchings" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "ietf-pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stefan,

I have two reasonably straightforward comments.

1. Section 3 defines an OCSP request extension, but neglects to specify
which of the two extension lists (requestExtensions or
singleRequestExtensions) the extension should be included in.

2. Section 4.1, item 3 refers to the "signing algorithm used to sign the
CertID specified in the query", however, the CertID is not signed. Is
this meant to specify that the server use the signing algorithm used by
the client to sign the entire OCSPRequest, or to specify that the server
use the signing algorithm used by the CA to sign the certificate
identified by the CertID? If the answer is the latter, what is the
expected behavior if the request queries multiple certificates that were
signed using different signature algorithms?

Thanks,
Seth Hitchings
CoreStreet, Ltd.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Wednesday, August 12, 2009 9:06 AM
To: Santosh Chokhani; ietf-pkix
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt


Santosh,

Thank you for your extensive review.

Instead of arguing all details in a mail, I have updated the draft,
following most of your recommendations.

The new draft is available here:
http://www.ietf.org/id/draft-ietf-pkix-ocspagility-02.txt

I have done nothing about comment 6 and 7.
Do you have any proposal on what specific changes you would like to
make?

Let me know if this draft resolves your comments?

/Stefan


On 09-08-10 6:04 PM, "Santosh Chokhani" <[e-mail]> wrote:

>=20
> I had sent the following comments and Recommendations for the I-D to
> Stefan last week.  This may of interest to others.
>=20
> COMMENT 1
> Section 2, Paragraph 1 states: "A particular OCSP server
>    may or may not be provided by the CA that issued the certificate
>    whose status is being queried and may or may provide a realtime
>    indication of the certificate status or a time delayed status
>    indication.".
>=20
> The above should be changed to: "An OCSP Responder may or may not be
> issued an OCSP Responder certificate by the CA that issued the
> certificate whose status is being queried.  An OCSP Responder may
> provide pre-signed OCSP responses, OCSP responses freshly signed in
> response to an OCSP request, or a combination of the two."
>=20
> COMMENT 2
> Section 2, Paragraph 4 states: "While the responder may apply
heuristics
> such as using the signature
>    algorithm employed by the certificate issuer, such heuristics fail
in
>    many common real-world situations where multiple signature
algorithms
>    are employed:"
>=20
> The whole premise of using certificate signing algorithm seems to be
> false.  It should be based on CRL signing.  Second 2 starting with
> paragraph 4 and including first set of bullets and short paragraph
> following the bullets should be revised as follows:
>=20
> "While an OCSP Responder may apply rules such as using the signature
> algorithm employed by the CA for CRL signing, the rule may not work in
> the following circumstances:
>=20
> o Algorithm used to sign the CRL may not be consistent with key pair
> being used by the OCSP Responder to sign responses."
>=20
> I do not see how the remaining three bullets will be applicable.
>=20
> COMMENT 3
> The following should be deleted from Section 2: "The last criterion is
> significant as it occurs frequently in real world PKI deployments and
> cannot be resolved through the information
>    available from in-band signalling using the RFC 2560 [RFC2560]
>    protocol without modification"
>=20
> COMMENT 4
> Section 2 states "In addition, a system that employs a signature
> algorithm other than
>    the de-facto default is frequently doing so to achieve very
specific
>    security properties that may not be captured by a heuristic
>    assumptuion designed to facilitate interoperability rather than
>    performance.  In particular:
>=20
>    o  An implementation may intentionally employ an algorithm for
>       certificate status response that is less computationally
demanding
>       than for signing the certificate itself, thus allowing for more
>       frequent certificate status validation.
>=20
>    o  An implementation may intentionally wish to guard against the
>       possibility of a compromise resulting from a signature algorithm
>       compromise by employing two separate encryption algorithms."
>=20
> This should be changed as follows: "An OCSP Responder may wish to
employ
> different signature algorithm that the CRL signing algorithm for the
> following reasons:
>=20
>    o  In order to generate pre-signed response more frequently or to
> meet the demand, the OCSP Responder may wish to employ a signing
> algorithm that is computationally less demanding for signature
> generation that the CRL signing algorithm
>      =20
>    o  A PKI may wish to guard against the possibility of a compromise
> resulting from a signature algorithm compromise by employing two
> separate signature algorithms for CRL and OCSP signing, thus allowing
> the relying parties to employ one mechanism or other for certificate
> status validation."
>=20
> COMMENT 5
> Section 3 states: "A client MAY declare a preferred set of algorithms
> algorithms in a
>    request using the preferred signature algorithm extension."
>=20
> Change it as follows: "A client MAY declare a preferred set of
> algorithms in a request using the preferred signature algorithms
> extension."
>=20
> COMMENT 6
> Section 3, Should there be an indication these should be Algorithm
> Identifiers asserted in SIGNED MACRO and Signature field as opposed to
> those asserted in subject public key information?
>=20
> COMMENT 7
> Section 3, Should it discuss what the impact is of the curves to be
> used?  Clients may not employ the curves in use by the server.
>=20
> COMMENT 8
> Section states: "If a set of preferred signature algorithms is
declared
> the client
>    MUST support each of the specified algorithms"
>=20
> This should be changed to "If a set of preferred signature algorithms
is
> specified by the client in the OCSP request, the client MUST support
> each of the specified algorithms."
>=20
> COMMENT 9
> Section 4.1 and 4.2 need to stress that the OCSP Responder SHALL use
> signing algorithm whose cryptographic bit security is acceptable to
the
> OCSP Responder.
>=20
> COMMENT 10
> Section 4.1, 2nd choice should be CRL signing algorithm.  Thus, switch
> number 2 and 3.
>=20
> COMMENT 11
> Section 7.2 should be revised as follows:
>=20
>    "The mechanism to support client indication of preferred signature
>    algorithms is not protected against a man in the middle downgrade
>    attack.  This constraint is not considered to be a significant
>    security concern since the OCSP Responder MUST NOT sign OCSP
> Responses using weak algorithms even if requested by the client.  In
> addition, the client can reject OCSP responses that do not meet its
own
> criteria for acceptable cryptographic security no matter what
mechanism
> is used to determine the signing algorithm of the response.  This can
be
> achieved using the DSSC I-D."
>=20
> COMMENT 12
> The document needs additional editing.
>=20
> Santosh Chokhani
> CygnaCom Solutions
>=20
> "Questioning conventional wisdom is key to innovation"
>=20




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7EE6gES092742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 07:06:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7EE6gXj092741; Fri, 14 Aug 2009 07:06:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7EE6dSI092733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 14 Aug 2009 07:06:41 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 4612 invoked from network); 14 Aug 2009 14:06:43 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 14 Aug 2009 14:06:43 -0000
Received: (qmail 13570 invoked from network); 14 Aug 2009 14:06:38 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.3]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 14 Aug 2009 14:06:38 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 14 Aug 2009 16:06:33 +0200
Subject: Certificate image - remaining issues
From: Stefan Santesson <[e-mail]>
To: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Certificate image - remaining issues
Thread-Index: Acoc6G2VBEQ8L6cllEy8TX4i4L4hig==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3333110798_8319961"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3333110798_8319961
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Apart from embedded images the current draft list one more open issue

   Issue: Image formats

      This draft recommends that certificate images are stored in a
      scalable format and specifically defines how to include images in
      PDF/A [ISO19005] and SVG Tiny [SVGT1.2] format. A third popular
      scalable vector graphic format VML (Vector graphic Markup
      Language) is not a public standard. Nevertheless, some
      implementers have chosen to support VML instead of SVG. It might
      therefore be useful to specify how to reference a VML formatted
      certificate image in an informational annex.


I would like to drop VML in absence of any stable specification of this
image format.
If anyone disagrees or know any other scalable image format that we should
consider, let me know.

/Stefan







--B_3333110798_8319961
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Certificate image - remaining issues</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Apart from embedded images the current draft list one more open issue<BR>
<BR>
&nbsp;&nbsp;&nbsp;Issue: Image formats<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This draft recommends that certificate =
images are stored in a<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;scalable format and specifically define=
s how to include images in<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PDF/A [ISO19005] and SVG Tiny [SVGT1.2]=
 format. A third popular<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;scalable vector graphic format VML (Vec=
tor graphic Markup<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Language) is not a public standard. Nev=
ertheless, some<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implementers have chosen to support VML=
 instead of SVG. It might<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;therefore be useful to specify how to r=
eference a VML formatted<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;certificate image in an informational a=
nnex.<BR>
<BR>
<BR>
I would like to drop VML in absence of any stable specification of this ima=
ge format.<BR>
If anyone disagrees or know any other scalable image format that we should =
consider, let me know.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3333110798_8319961--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7EDhekn091335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 06:43:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7EDhe9f091334; Fri, 14 Aug 2009 06:43:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7EDhSPj091323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 14 Aug 2009 06:43:38 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 426 invoked from network); 14 Aug 2009 13:43:31 -0000
Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 14 Aug 2009 13:43:31 -0000
Received: (qmail 10197 invoked from network); 14 Aug 2009 13:43:26 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.3]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 14 Aug 2009 13:43:26 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 14 Aug 2009 15:43:24 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[e-mail]>
To: Stephen Kent <[e-mail]>, "Kemp, David P." <[e-mail]>
CC: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: Embedded certificate image
Thread-Index: Acoc5TGtFpeZZ3SPtUK2sH9JJEsbFg==
In-Reply-To: <p06240806c69df525a82d@[128.89.89.105]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to conclude this discussion, at least with respect to this
draft.

The fact of the case is that the scope of this draft is limited to defining
a new image type to be referenced through the logotype extension defined in
RFC3709.

All RFC 3709 allows in this context is to define an OID and its semantics.
There are no extensibility mechanism available through which one can provide
any extra random bits to the image.

The question is therefore not what could be done to safely include image
data in a certificate signed with a poor signature algorithm, but if it is
reasonable to reference the data URL scheme as one optional way to store the
referenced image without adding any random data.

My proposal is to allow the data url scheme for embedding an image, but to
clarify the risk of including images provided by a potential attacker in
combination with a week signing hash.

Would anyone strongly object?

/Stefan


On 09-08-04 4:27 PM, "Stephen Kent" <[e-mail]> wrote:

> 
> At 4:46 PM -0400 8/3/09, Kemp, David P. wrote:
>> If a CA were going to accept user input to an image composed by the CA,
>> then the composition process can provide confounding data by doing more
>> than just "inserting a customer-provided graphic into a [known] template
>> provided by the CA".  The Security Considerations section could
>> recommend steganographic techniques for unpredictably modifying the
>> image in perceptually-insignificant ways, such as by adding noise to the
>> image data and/or inserting random tags in image formats for which tags
>> are defined.
>> 
> 
> David,
> 
> I think a CA-selected, random prefix may be a better choice here. An
> organization may be very "attached" to its logo and not want any form
> of manipulation.  In many (most?) cases I expect the organization to
> provide the artwork in precisely the form they will want it to be
> displayed. It would be much easier for a CA to just generate random
> bit string and insert in into a data structure used to convey the
> image, rather than having to be able to watermark the image in some
> fahsion.
> 
> Steve
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7E1J5ow044357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 18:19:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7E1J5Eg044356; Thu, 13 Aug 2009 18:19:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7E1IxVO044335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 18:19:00 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240849c6aa6bc162b7@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 13 Aug 2009 18:18:39 -0700
To: Sean Turner <[e-mail]>, [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-new-asn1-06.txt
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:52 PM -0400 8/13/09, Sean Turner wrote:
>Paul/Jim,
>
>The change to noted in A.7 didn't get implemented in the Section 6.  If you're going to use the comment out method, then you need to comment out the "," at the end of the namedCurve line:
>
>ECParameters ::= CHOICE {
>  namedCurve      CURVE.&id({NamedCurve}) --,
>                                          ^^ add this
>  -- implicitCurve   NULL
>    -- implicitCurve MUST NOT be used in PKIX
>  -- specifiedCurve  SpecifiedCurve
>    -- specifiedCurve MUST NOT be used in PKIX
>    -- Details for specifiedCurve can be found in [X9.62]
>    -- Any future additions to this CHOICE should be coordinated
>    -- with ANSI X.9.
> }
> -- If you need to be able to decode ANSI X.9 parameter structures, then
> -- uncomment the implicitCurve and specificCurve above, and also
> -- uncomment the follow:
> --(WITH COMPONENTS {namedCurve PRESENT})
>
>spt

That was my fault for not checking if the changes went in. They are in the -07, particularly with the additional change you made above.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7E1F7Dk044107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 18:15:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7E1F7oc044105; Thu, 13 Aug 2009 18:15:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7E1F687044093 for <[e-mail]>; Thu, 13 Aug 2009 18:15:07 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id D7C073A696C; Thu, 13 Aug 2009 18:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-new-asn1-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 13 Aug 2009 18:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.


	Title           : New ASN.1 Modules for PKIX
	Author(s)       : P. Hoffman, J. Schaad
	Filename        : draft-ietf-pkix-new-asn1-07.txt
	Pages           : 120
	Date            : 2009-08-13

The PKIX certificate format, and many associated formats, are
expressed using ASN.1.  The current ASN.1 modules conform to the 1988
version of ASN.1.  This document updates those ASN.1 modules to
conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
changes to any of the formats; this is simply a change to the syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-new-asn1-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7DKqmgU030010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 13:52:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7DKqlUH030009; Thu, 13 Aug 2009 13:52:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7DKqkPw030000 for <[e-mail]>; Thu, 13 Aug 2009 13:52:47 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 79002 invoked from network); 13 Aug 2009 20:52:46 -0000
Received: from unknown (HELO thunderfish.local) (turners@71.191.9.200 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 13 Aug 2009 20:52:45 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: o3iVEOsVM1mtk6YSowgFc_goLknoHjIOP49t1if4hs91Y_FxdjcTlWaBeffy6ODsu1By9yVG499J7WFezMitDc6H8MKlrnAkYuZdTg46wxRWC8f.qOcE1IPtm.xA89DPhjkjaBZ2UO8Vx1Scc7IPgiQkNxaRi.4_VZzsju.kTMxwDZU_6k42PqQUaSCdbuyy8p2n.Uj2RwAYs9XUh7WX8hAwuJUkzHDvz3kUY1vi.PINkFkzcnxK1.Ba3U_WdFYNAfenWEgRUWovqS2wG.QGl0OEAjpcVOp35EymEHYmqbVLSwaw4r5ZpeY1qAUVr.Fo2oDZ.dp.6GBf7Y1sIixvCeVbVSCrj8cvDMk-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Thu, 13 Aug 2009 16:52:45 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-new-asn1-06.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul/Jim,

The change to noted in A.7 didn't get implemented in the Section 6.  If 
you're going to use the comment out method, then you need to comment out 
the "," at the end of the namedCurve line:

ECParameters ::= CHOICE {
   namedCurve      CURVE.&id({NamedCurve}) --,
                                           ^^ add this
   -- implicitCurve   NULL
     -- implicitCurve MUST NOT be used in PKIX
   -- specifiedCurve  SpecifiedCurve
     -- specifiedCurve MUST NOT be used in PKIX
     -- Details for specifiedCurve can be found in [X9.62]
     -- Any future additions to this CHOICE should be coordinated
     -- with ANSI X.9.
  }
  -- If you need to be able to decode ANSI X.9 parameter structures, then
  -- uncomment the implicitCurve and specificCurve above, and also
  -- uncomment the follow:
  --(WITH COMPONENTS {namedCurve PRESENT})

spt

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 
> 	Title           : New ASN.1 Modules for PKIX
> 	Author(s)       : P. Hoffman, J. Schaad
> 	Filename        : draft-ietf-pkix-new-asn1-06.txt
> 	Pages           : 120
> 	Date            : 2009-08-13
> 
> The PKIX certificate format, and many associated formats, are
> expressed using ASN.1.  The current ASN.1 modules conform to the 1988
> version of ASN.1.  This document updates those ASN.1 modules to
> conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
> changes to any of the formats; this is simply a change to the syntax.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-06.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7DDF7P6095117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 06:15:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7DDF7Oh095114; Thu, 13 Aug 2009 06:15:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7DDF6c6095102 for <[e-mail]>; Thu, 13 Aug 2009 06:15:06 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 686D93A6973; Thu, 13 Aug 2009 06:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-new-asn1-06.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 13 Aug 2009 06:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.


	Title           : New ASN.1 Modules for PKIX
	Author(s)       : P. Hoffman, J. Schaad
	Filename        : draft-ietf-pkix-new-asn1-06.txt
	Pages           : 120
	Date            : 2009-08-13

The PKIX certificate format, and many associated formats, are
expressed using ASN.1.  The current ASN.1 modules conform to the 1988
version of ASN.1.  This document updates those ASN.1 modules to
conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
changes to any of the formats; this is simply a change to the syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-new-asn1-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CMbFVI040902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 15:37:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CMbF7h040901; Wed, 12 Aug 2009 15:37:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CMb6Iu040892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 12 Aug 2009 15:37:13 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id a14438a4.3688217520.43299.00-007.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Wed, 12 Aug 2009 16:37:14 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Wed, 12 Aug 2009 18:37:05 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
thread-index: AcobnWrZMPHiDYpfS5iYZKvbq/Sh0Q==
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Thanks for addressing most of my concerns.  I have two partial concerns
remaining from old comments.  I have also recommended text for two
questions you had, but would like folks who specify Algorithm Identifier
ASN.1 to make sure they are ok with it.

There are no new comments below.

COMMENT 1
Section 2 states:

   "o  An implementation may intentionally wish to guard against the
      possibility of a compromise resulting from a signature algorithm
      compromise by employing two separate encryption algorithms."

This should be changed as follows:=20
     =20
   "o  A PKI may wish to guard against the possibility of a compromise
resulting from a signature algorithm compromise by employing two
separate signature algorithms for CRL and OCSP signing, thus allowing
the relying parties to employ one mechanism or other for certificate
status validation."

COMMENT 2
Section 3, The Algorithm Identifier should be one asserted in SIGNED
MACRO or Signature field in order to cover hashing algorithms.

COMMENT 3
Section 3, Unlike SIGNED MACRO and Signature field, the Algorithm
Identifier can contain parameters for the client to declare its
constraints.  For example, a client who only processes Suite B curves
only may do so by using the following ASN.1 structure:

SEQUENCE {
	SEQUENCE {ecdsa-with-SHA256 OBJECT IDENTIFIER
		    secp256r1 OBJECT IDENTIFIER}
	SEQUENCE {ecdsa-with-SHA384 OBJECT IDENTIFIER
		    secp384r1 OBJECT IDENTIFIER}
	    }

If we have argument on populating these OIDs with parameters (e.g.,
based on RFC 5480), we may need to come up with different ASN.1.

COMMENT 4
Section 7.2 should be revised to reference LTANS DSSC I-D to shield the
client against weak algorithms.  It is desirable that IETF standards
build on each other.=20


Santosh Chokhani
CygnaCom Solutions



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CEc5r2009936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 07:38:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CEc5DW009935; Wed, 12 Aug 2009 07:38:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CEc1TF009927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 12 Aug 2009 07:38:04 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO p03c11o142.symantecmail.net) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id cc3d28a4.2238135216.603371.00-508.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Wed, 12 Aug 2009 08:38:04 -0600 (MDT)
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 7c3d28a4.2806684592.603363.00-011.p03c11o142.symantecmail.net (envelope-from <[e-mail]>); Wed, 12 Aug 2009 08:37:59 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Date: Wed, 12 Aug 2009 10:37:57 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
thread-index: Acoaobq/ssr8RbsWRVy+bZD3u15ExQAI3ZUAABk354AAC8MCkA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Skedd, Richard (UK)" <[e-mail]>
Cc: "Rob Sherwood" <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For Item 1,
See paragraph 3 of Section 1 of the I-D.  Also, note that the I-D also
covers when the clearance is NOT asserted in a public key certificate
and is asserted in an attribute certificate.  Finally, this topic has
been discussed during the I-D formulation and review.  For that, see
PKIX archives.

For Item 3,
The I-D works independent of the specific meaning of the bits.  The bits
may be required due the default value of unclassified.  This may be a
legitimate comment against the current I-D that revises RC 3281.
=20

> -----Original Message-----
> From: Skedd, Richard (UK) [mailto:[e-mail]]=20
> Sent: Wednesday, August 12, 2009 7:25 AM
> To: Santosh Chokhani
> Cc: Rob Sherwood; [e-mail]
> Subject: RE: TSCP Comments on=20
> draft-ietf-pkix-authorityclearanceconstraints-02.txt
>=20
> Two comments on the points and responses below:
>=20
> 1.  Intent - I understand the value of clearance constraints=20
> if you are going to include clearance attributes in PKCs but=20
> don't understand the use case for the inclusion of clearance=20
> attributes in PKCs.  Perhaps you could explain further.
>=20
> 3.  Clearances - I was interested in the comments regarding=20
> the ClassList at item 3 below as the proposed list, to UK=20
> eyes, appears to be completely arbitrary in scope and order.
>=20
> I looked at RFC 3281 as suggested, this appears to just adopt=20
> X.501-1993.  I could not find anything in X.501-1993 refering=20
> to clearance.  RFC2634 and X.411-1997 refer to a very similar=20
> list as Security Classifications:
>=20
>   unmarked (0),
>   unclassified (1),
>   restricted (2),
>   confidential (3),
>   secret (4),
>   top-secret (5)
>=20
> But note that this is slightly different to that proposed in=20
> the draft for Top Secret which is given as "topSecret".
>=20
> At that point I gave up, if someone could enlighten me on=20
> where the list came from and why it is still correct in 2009=20
> I would be grateful.
>=20
> I am also unsure of the value of a reserved list of text=20
> strings when the application of the policyId field makes the=20
> actual meaning of all entries in the ClassList policy=20
> specific.  There may also be problems where a particular=20
> policy uses the values in the ClassList but in a different=20
> hierarchical order.
>=20
> Regards
> =20
> Richard Skedd
> IT Strategy Manager
> T:    [phone] (vnet 7658 8034)
> M:    [phone] (vnet 777118260)
> =20
> BAE Systems plc
> Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK=20
> Registered in England & Wales No: 1470151=20
>=20
> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: 11 August 2009 22:06
> To: Rob Sherwood; [e-mail]
> Subject: RE: TSCP Comments on
> draft-ietf-pkix-authorityclearanceconstraints-02.txt
>=20
>=20
>                     *** WARNING ***
>=20
>   This message has originated outside your organisation,
>   either from an external partner or the Global Internet.=20
>       Keep this in mind if you answer this message.
>=20
>=20
> Rob,
>=20
> See responses in-line below.=20
>=20
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Rob Sherwood
> > Sent: Tuesday, August 11, 2009 12:35 PM
> > To: [e-mail]
> > Subject: TSCP Comments on
> > draft-ietf-pkix-authorityclearanceconstraints-02.txt
> >=20
> >=20
> > I am writing this message on behalf of the TSCP=20
> (http://www.tscp.org),
>=20
> > to present our thoughts on the draft specification "Clearance=20
> > Attribute and Authority Clearance Constraints Certificate Extension"
> > (draft-ietf-pkix-authorityclearanceconstraints-02.txt). Based on=20
> > review of the specification with our TSCP membership and=20
> discussion of
>=20
> > the proposal, we wish to raise the following concerns regarding this
> > specification:
> >=20
> > 1. Firstly, there is no articulation of intent for use of this=20
> > standard in an implementation. It is unclear whether this is a=20
> > solution in search of a problem, or whether a use case has been=20
> > articulated. Given the close relationship between the=20
> CertiPath/TSCP=20
> > membership and the DoD, we are concerned that the unknown=20
> use case may
>=20
> > impact the certificate profile or policy currently=20
> implemented within=20
> > the A&D Community.
> > Accordingly, the A&D community represented in the TSCP=20
> would like to=20
> > have visibility regarding the intent of the standard.
> [Santosh] Last two paragraphs of Section 1 of the I-D provide=20
> when clearance constraints may be useful.  Once clearance=20
> constraint is used, the relying parties need to enforce the=20
> intent of the clearance constraint during certificate path validation.
> =20
> >=20
> > 2. In many cases, individuals are forbidden to disclose the=20
> fact that=20
> > they hold a clearance. This proposal, if adopted for use in human=20
> > subscriber certificates, would either force violation of=20
> this rule or=20
> > create the need for individuals to maintain multiple certificates.
> [Santosh] Section 9 of the I-D deals with how to use this information.
> Please note that the I-D is not proposing that clearance or=20
> clearance constraint will be a mandatory requirement for certificates.
>=20
> >=20
> > 3. The list of clearances (ClassList) is incorrect. It=20
> appears to be a
>=20
> > mixture of clearances and data sensitivity markings. This makes the=20
> > intent of the specification unclear, as it seems to be=20
> applicable to=20
> > both individuals and resource managers.
> [Santosh] The classification list is from an existing vetted=20
> clearance attribute defined in RFC 3281.
>=20
> >=20
> > 4. Clearance level declarations are incomplete. Declaration of=20
> > clearance without investigation level (NACI, Poly, etc) and issuer=20
> > (DoD, Treasury,
> > etc.) is insufficient to determine what resources may be shared.
> [Santosh] The policyID object identifier in the clearance=20
> structure defines the security policy to which the clearance=20
> relates.  That should cover issuer and investigation level. =20
>=20
> >=20
> > 5. A specification of sensitivity/clearance in a certificate may be=20
> > useful for device certs or attribute certs, as a way to ensure that=20
> > networks of a certain classification are closed, and that=20
> > communication within and between them is protected, however=20
> the issues
>=20
> > with the clearance list suggest that this proposal may not=20
> serve this=20
> > need.
> [Santosh] The I-D deals with "subject".  Subject can be human=20
> or non-human entity.
>=20
> >=20
> > We are not necessarily opposed to the specification, but we would=20
> > first like to understand the details of the intent behind the=20
> > specification, and would like to discuss the issues with the draft=20
> > specification documented above.
> >=20
> > Robert Sherwood
> > Design Authority | Transglobal Secure Collaboration Authority 13530=20
> > Dulles Technology Dr, Ste 200, Herndon, VA 20171 PH
> > +1.703.793.7705 (W) +1.703.362.2329 (M)
> >=20
> >=20
> >=20
>=20
>=20
>=20
> ********************************************************************
> This email and any attachments are confidential to the=20
> intended recipient and may also be privileged. If you are not=20
> the intended recipient please delete it from your system and=20
> notify the sender.
> You should not copy it or use it for any purpose nor disclose=20
> or distribute its contents to any other person.
> ********************************************************************
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CEaw4Z009850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 07:36:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CEawrK009849; Wed, 12 Aug 2009 07:36:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7CEaqDU009836 for <[e-mail]>; Wed, 12 Aug 2009 07:36:56 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 4159 invoked from network); 12 Aug 2009 14:36:52 -0000
Received: from unknown (HELO thunderfish.local) (turners@71.191.12.61 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 12 Aug 2009 14:36:51 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 3920z_oVM1kbmCkNwzuObEZh3YjRtgYjI9cdNSjR6TZTfPFdwDztHyqAx4fwXa8MbjArPNe5onkpMpkMO9bwwjAc2NUJiKI8iFT2ZUUPXEzxr81ruHWk.pZ3E5vMp.u3rqBd0FB_ukfsIvgpF.n80ewgFuqYVk8tTd4feRNBZZ2zsPha4GMQZKT7MHkxpqr.1TDBpPrVd4odR30ZUq1IXj0E4O8lVbIKCCVRXeMpHjtTVlwYIXaBqqefOFo7deFUHxYObFu4YX.2G8y39jBRwIieQaL4u_31ML_HhYbg87X89SqLrJCGQKxekvWvd8PK2GZpoOwST9gRvajNNSieG3Wo_LFHb9mnzg--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Wed, 12 Aug 2009 10:36:50 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: "Skedd, Richard (UK)" <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, Rob Sherwood <[e-mail]>, [e-mail]
Subject: Re: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Skedd, Richard (UK) wrote:
> Two comments on the points and responses below:
> 
> 1.  Intent - I understand the value of clearance constraints if you are
> going to include clearance attributes in PKCs but don't understand the
> use case for the inclusion of clearance attributes in PKCs.  Perhaps you
> could explain further.

The use case for clearance in a public key certificate is pretty 
straightforward: a) follow certificate policy that requires clearance be 
included in public key certificate b) include clearance information in a 
subscriber's public key certificate c) relying party uses clearance to 
make an authorization decision.  If we throw in authority clearance 
constraints, then the relying party also checks that issuer was allowed 
to issue clearance in subscriber's certificate between b) and c). 
There's many examples including clearance in public key certificates, as 
noted by Steve Kent on 2/21/08 his "secure phone has always contained 
clearance info, for 20+ years."

I'd rather not reopen the "clearances are too dynamic to put in public 
key certificate" discussion.  This document isn't requiring that they be 
included in every certificate (a CP would do that).  We're just 
providing an interoperable way to do it.  If somebody really wanted to 
associate more dynamic clearances with a subject, they should put them 
in attribute certificates and we have sections to address that.

> 3.  Clearances - I was interested in the comments regarding the
> ClassList at item 3 below as the proposed list, to UK eyes, appears to
> be completely arbitrary in scope and order.
> 
> I looked at RFC 3281 as suggested, this appears to just adopt
> X.501-1993.  I could not find anything in X.501-1993 refering to
> clearance.  RFC2634 and X.411-1997 refer to a very similar list as
> Security Classifications:
> 
>   unmarked (0),
>   unclassified (1),
>   restricted (2),
>   confidential (3),
>   secret (4),
>   top-secret (5)
> 
> But note that this is slightly different to that proposed in the draft
> for Top Secret which is given as "topSecret".
> 
> At that point I gave up, if someone could enlighten me on where the list
> came from and why it is still correct in 2009 I would be grateful.

The clearance attribute is based on the X.411-1988 security-label 
attribute.  Clearance is different in a couple of ways a) policy-Id 
required b) privacy-mark removed c) classList is a bit string vice 
integer d) topSecret vice top-secret.   All of the differences were 
purposeful except maybe for the last one.

I'd say the list is still correct in 2009 because it contains the basic 
classification used by many.  I wasn't there in 1988, but I suspect that 
to navigate the international standards gauntlet that they had to pick 
something to call the fields and they went with what they knew, which 
might have been based on some national input or knowledge of James Bond 
books (betting on the former).  X.411/X.501/RFC 3281 are all extensible 
so it met the international standards bar of providing basic 
interoperability while allowing those that want something more exotic to 
specify it.

I also don't want to throw these structures out because there is 
implementation experience with both clearance/security-label attributes.

> I am also unsure of the value of a reserved list of text strings when
> the application of the policyId field makes the actual meaning of all
> entries in the ClassList policy specific.  There may also be problems
> where a particular policy uses the values in the ClassList but in a
> different hierarchical order.

The reserved text field isn't transfered so an implementation that chose 
to display a value for the bits could show secret, SECRET, or 
COUNTRY-NAME SECRET.  Note that display is not addressed by this document.

As you pointed out the ClassList is extensible so if a policy needs to 
add more it can.  The access control decision point is going to need 
more information than just the clearance values. It's going to need to 
know which one dominates the others.

spt

> Regards
>  
> Richard Skedd
> IT Strategy Manager
> T:    [phone] (vnet 7658 8034)
> M:    [phone] (vnet 777118260)
>  
> BAE Systems plc
> Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK
> Registered in England & Wales No: 1470151 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: 11 August 2009 22:06
> To: Rob Sherwood; [e-mail]
> Subject: RE: TSCP Comments on
> draft-ietf-pkix-authorityclearanceconstraints-02.txt
> 
> 
>                     *** WARNING ***
> 
>   This message has originated outside your organisation,
>   either from an external partner or the Global Internet. 
>       Keep this in mind if you answer this message.
> 
> 
> Rob,
> 
> See responses in-line below. 
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Rob Sherwood
>> Sent: Tuesday, August 11, 2009 12:35 PM
>> To: [e-mail]
>> Subject: TSCP Comments on
>> draft-ietf-pkix-authorityclearanceconstraints-02.txt
>>
>>
>> I am writing this message on behalf of the TSCP (http://www.tscp.org),
> 
>> to present our thoughts on the draft specification "Clearance 
>> Attribute and Authority Clearance Constraints Certificate Extension"
>> (draft-ietf-pkix-authorityclearanceconstraints-02.txt). Based on 
>> review of the specification with our TSCP membership and discussion of
> 
>> the proposal, we wish to raise the following concerns regarding this
>> specification:
>>
>> 1. Firstly, there is no articulation of intent for use of this 
>> standard in an implementation. It is unclear whether this is a 
>> solution in search of a problem, or whether a use case has been 
>> articulated. Given the close relationship between the CertiPath/TSCP 
>> membership and the DoD, we are concerned that the unknown use case may
> 
>> impact the certificate profile or policy currently implemented within 
>> the A&D Community.
>> Accordingly, the A&D community represented in the TSCP would like to 
>> have visibility regarding the intent of the standard.
> [Santosh] Last two paragraphs of Section 1 of the I-D provide when
> clearance constraints may be useful.  Once clearance constraint is used,
> the relying parties need to enforce the intent of the clearance
> constraint during certificate path validation.
>  
>> 2. In many cases, individuals are forbidden to disclose the fact that 
>> they hold a clearance. This proposal, if adopted for use in human 
>> subscriber certificates, would either force violation of this rule or 
>> create the need for individuals to maintain multiple certificates.
> [Santosh] Section 9 of the I-D deals with how to use this information.
> Please note that the I-D is not proposing that clearance or clearance
> constraint will be a mandatory requirement for certificates.
> 
>> 3. The list of clearances (ClassList) is incorrect. It appears to be a
> 
>> mixture of clearances and data sensitivity markings. This makes the 
>> intent of the specification unclear, as it seems to be applicable to 
>> both individuals and resource managers.
> [Santosh] The classification list is from an existing vetted clearance
> attribute defined in RFC 3281.
> 
>> 4. Clearance level declarations are incomplete. Declaration of 
>> clearance without investigation level (NACI, Poly, etc) and issuer 
>> (DoD, Treasury,
>> etc.) is insufficient to determine what resources may be shared.
> [Santosh] The policyID object identifier in the clearance structure
> defines the security policy to which the clearance relates.  That should
> cover issuer and investigation level.  
> 
>> 5. A specification of sensitivity/clearance in a certificate may be 
>> useful for device certs or attribute certs, as a way to ensure that 
>> networks of a certain classification are closed, and that 
>> communication within and between them is protected, however the issues
> 
>> with the clearance list suggest that this proposal may not serve this 
>> need.
> [Santosh] The I-D deals with "subject".  Subject can be human or
> non-human entity.
> 
>> We are not necessarily opposed to the specification, but we would 
>> first like to understand the details of the intent behind the 
>> specification, and would like to discuss the issues with the draft 
>> specification documented above.
>>
>> Robert Sherwood
>> Design Authority | Transglobal Secure Collaboration Authority 13530 
>> Dulles Technology Dr, Ste 200, Herndon, VA 20171 PH
>> +1.703.793.7705 (W) +1.703.362.2329 (M)
>>
>>
>>
> 
> 
> 
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CEJ5ns008662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 07:19:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CEJ5Kp008659; Wed, 12 Aug 2009 07:19:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CEIrJf008629 for <[e-mail]>; Wed, 12 Aug 2009 07:19:04 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7FB20F24005; Wed, 12 Aug 2009 10:18:56 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id IfpFiVvR3UN8; Wed, 12 Aug 2009 10:18:52 -0400 (EDT)
Received: from THINKPADR52.vigilsec.com (pool-96-241-154-102.washdc.fios.verizon.net [96.241.154.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 35D90F2402C; Wed, 12 Aug 2009 10:18:55 -0400 (EDT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 12 Aug 2009 10:18:47 -0400
To: "Manger, James H" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt 
Cc: [e-mail]
In-Reply-To: <[e-mail]. dir.telstra.com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for the review.

How about: This document specifies a MIME content type used to carry 
a single attribute certificate as defined in RFC 3281.

RFC 3281 tells what parts must be DER encoded and which parts are 
allowed to be BER encoded.

I'll fix the typo.

Russ


At 11:47 PM 8/11/2009, Manger, James H wrote:
>Comment on draft-ietf-pkix-attr-cert-mime-type-00.txt
>
>There isn't a clear statement of what the content is when the MIME 
>type is application/pkix-attr-cert.
>I assume it is a single DER-encoded attribute certificate -- not a 
>chain of ACs, not PEM-encoded, not in a package that can also hold 
>associated public-key certs or CRLs. A sentence stating this would help.
>
>Typo: the opening words of the Introduction are "RFC 2528", but 
>should be "RFC 2585".
>
>James Manger
>[e-mail]
>Identity and security team — Chief Technology Office — Telselstra
>
>----------
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of [e-mail]
>Sent: Wednesday, 12 August 2009 7:00 AM
>Subject: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) 
>Working Group of the IETF.
>
>
>         Title           : The application/pkix-attr-cert Content 
> Type for Attribute Certificates
>         Author(s)       : R. Housley
>         Filename        : draft-ietf-pkix-attr-cert-mime-type-00.txt
>         Pages           : 3
>         Date            : 2009-08-11
>
>This document specifies a MIME content type for use with attribute
>certificates as defined in RFC 3281.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-attr-cert-mime-type-00.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CECD68008089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 07:12:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CECCf5008088; Wed, 12 Aug 2009 07:12:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CEC0K7008070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 12 Aug 2009 07:12:11 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id bbdc28a4.1855454128.103800.00-008.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Wed, 12 Aug 2009 08:12:11 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Date: Wed, 12 Aug 2009 10:11:59 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-01.txt
thread-index: AcoZ1DbkFeo2XmhRRhq2Obxb6zRS1QBeXHLPAAJGZGA=
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "ietf-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Thanks.  I will  review version 2 and make comments including
suggestions for the two comments mentioned below by you.=20

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]=20
> Sent: Wednesday, August 12, 2009 9:06 AM
> To: Santosh Chokhani; ietf-pkix
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt
>=20
> Santosh,
>=20
> Thank you for your extensive review.
>=20
> Instead of arguing all details in a mail, I have updated the=20
> draft, following most of your recommendations.
>=20
> The new draft is available here:
> http://www.ietf.org/id/draft-ietf-pkix-ocspagility-02.txt
>=20
> I have done nothing about comment 6 and 7.
> Do you have any proposal on what specific changes you would=20
> like to make?
>=20
> Let me know if this draft resolves your comments?
>=20
> /Stefan
>=20
>=20
> On 09-08-10 6:04 PM, "Santosh Chokhani"=20
> <[e-mail]> wrote:
>=20
> >=20
> > I had sent the following comments and Recommendations for=20
> the I-D to=20
> > Stefan last week.  This may of interest to others.
> >=20
> > COMMENT 1
> > Section 2, Paragraph 1 states: "A particular OCSP server
> >    may or may not be provided by the CA that issued the certificate
> >    whose status is being queried and may or may provide a realtime
> >    indication of the certificate status or a time delayed status
> >    indication.".
> >=20
> > The above should be changed to: "An OCSP Responder may or=20
> may not be=20
> > issued an OCSP Responder certificate by the CA that issued the=20
> > certificate whose status is being queried.  An OCSP Responder may=20
> > provide pre-signed OCSP responses, OCSP responses freshly signed in=20
> > response to an OCSP request, or a combination of the two."
> >=20
> > COMMENT 2
> > Section 2, Paragraph 4 states: "While the responder may apply=20
> > heuristics such as using the signature
> >    algorithm employed by the certificate issuer, such=20
> heuristics fail in
> >    many common real-world situations where multiple=20
> signature algorithms
> >    are employed:"
> >=20
> > The whole premise of using certificate signing algorithm=20
> seems to be=20
> > false.  It should be based on CRL signing.  Second 2 starting with=20
> > paragraph 4 and including first set of bullets and short paragraph=20
> > following the bullets should be revised as follows:
> >=20
> > "While an OCSP Responder may apply rules such as using the=20
> signature=20
> > algorithm employed by the CA for CRL signing, the rule may=20
> not work in=20
> > the following circumstances:
> >=20
> > o Algorithm used to sign the CRL may not be consistent with=20
> key pair=20
> > being used by the OCSP Responder to sign responses."
> >=20
> > I do not see how the remaining three bullets will be applicable.
> >=20
> > COMMENT 3
> > The following should be deleted from Section 2: "The last=20
> criterion is=20
> > significant as it occurs frequently in real world PKI=20
> deployments and=20
> > cannot be resolved through the information
> >    available from in-band signalling using the RFC 2560 [RFC2560]
> >    protocol without modification"
> >=20
> > COMMENT 4
> > Section 2 states "In addition, a system that employs a signature=20
> > algorithm other than
> >    the de-facto default is frequently doing so to achieve=20
> very specific
> >    security properties that may not be captured by a heuristic
> >    assumptuion designed to facilitate interoperability rather than
> >    performance.  In particular:
> >=20
> >    o  An implementation may intentionally employ an algorithm for
> >       certificate status response that is less=20
> computationally demanding
> >       than for signing the certificate itself, thus=20
> allowing for more
> >       frequent certificate status validation.
> >=20
> >    o  An implementation may intentionally wish to guard against the
> >       possibility of a compromise resulting from a=20
> signature algorithm
> >       compromise by employing two separate encryption algorithms."
> >=20
> > This should be changed as follows: "An OCSP Responder may wish to=20
> > employ different signature algorithm that the CRL signing algorithm=20
> > for the following reasons:
> >=20
> >    o  In order to generate pre-signed response more=20
> frequently or to=20
> > meet the demand, the OCSP Responder may wish to employ a signing=20
> > algorithm that is computationally less demanding for signature=20
> > generation that the CRL signing algorithm
> >      =20
> >    o  A PKI may wish to guard against the possibility of a=20
> compromise=20
> > resulting from a signature algorithm compromise by employing two=20
> > separate signature algorithms for CRL and OCSP signing,=20
> thus allowing=20
> > the relying parties to employ one mechanism or other for=20
> certificate=20
> > status validation."
> >=20
> > COMMENT 5
> > Section 3 states: "A client MAY declare a preferred set of=20
> algorithms=20
> > algorithms in a
> >    request using the preferred signature algorithm extension."
> >=20
> > Change it as follows: "A client MAY declare a preferred set of=20
> > algorithms in a request using the preferred signature algorithms=20
> > extension."
> >=20
> > COMMENT 6
> > Section 3, Should there be an indication these should be Algorithm=20
> > Identifiers asserted in SIGNED MACRO and Signature field as=20
> opposed to=20
> > those asserted in subject public key information?
> >=20
> > COMMENT 7
> > Section 3, Should it discuss what the impact is of the curves to be=20
> > used?  Clients may not employ the curves in use by the server.
> >=20
> > COMMENT 8
> > Section states: "If a set of preferred signature algorithms is=20
> > declared the client
> >    MUST support each of the specified algorithms"
> >=20
> > This should be changed to "If a set of preferred signature=20
> algorithms=20
> > is specified by the client in the OCSP request, the client MUST=20
> > support each of the specified algorithms."
> >=20
> > COMMENT 9
> > Section 4.1 and 4.2 need to stress that the OCSP Responder=20
> SHALL use=20
> > signing algorithm whose cryptographic bit security is acceptable to=20
> > the OCSP Responder.
> >=20
> > COMMENT 10
> > Section 4.1, 2nd choice should be CRL signing algorithm. =20
> Thus, switch=20
> > number 2 and 3.
> >=20
> > COMMENT 11
> > Section 7.2 should be revised as follows:
> >=20
> >    "The mechanism to support client indication of preferred=20
> signature
> >    algorithms is not protected against a man in the middle downgrade
> >    attack.  This constraint is not considered to be a significant
> >    security concern since the OCSP Responder MUST NOT sign OCSP=20
> > Responses using weak algorithms even if requested by the=20
> client.  In=20
> > addition, the client can reject OCSP responses that do not meet its=20
> > own criteria for acceptable cryptographic security no matter what=20
> > mechanism is used to determine the signing algorithm of the=20
> response. =20
> > This can be achieved using the DSSC I-D."
> >=20
> > COMMENT 12
> > The document needs additional editing.
> >=20
> > Santosh Chokhani
> > CygnaCom Solutions
> >=20
> > "Questioning conventional wisdom is key to innovation"
> >=20
>=20
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CDF6mf002972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 06:15:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CDF6hm002971; Wed, 12 Aug 2009 06:15:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CDF51t002965 for <[e-mail]>; Wed, 12 Aug 2009 06:15:06 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 2DE123A6AB5; Wed, 12 Aug 2009 06:15:00 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ocspagility-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 12 Aug 2009 06:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.


	Title           : OCSP Algorithm Agility
	Author(s)       : P. Hallam-Baker, S. Santesson
	Filename        : draft-ietf-pkix-ocspagility-02.txt
	Pages           : 9
	Date            : 2009-08-12

The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspagility-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocspagility-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CD6IKx002230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 06:06:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CD6Ilo002229; Wed, 12 Aug 2009 06:06:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CD6FKc002217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 12 Aug 2009 06:06:17 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19506 invoked from network); 12 Aug 2009 13:06:18 -0000
Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender <[e-mail]>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <[e-mail]>; 12 Aug 2009 13:06:18 -0000
Received: (qmail 86594 invoked from network); 12 Aug 2009 13:06:13 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.3]) ([e-mail]@[213.64.142.97]) (envelope-sender <[e-mail]>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 12 Aug 2009 13:06:13 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 12 Aug 2009 15:06:09 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Thread-Index: AcoZ1DbkFeo2XmhRRhq2Obxb6zRS1QBeXHLP
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

Thank you for your extensive review.

Instead of arguing all details in a mail, I have updated the draft,
following most of your recommendations.

The new draft is available here:
http://www.ietf.org/id/draft-ietf-pkix-ocspagility-02.txt

I have done nothing about comment 6 and 7.
Do you have any proposal on what specific changes you would like to make?

Let me know if this draft resolves your comments?

/Stefan


On 09-08-10 6:04 PM, "Santosh Chokhani" <[e-mail]> wrote:

> 
> I had sent the following comments and Recommendations for the I-D to
> Stefan last week.  This may of interest to others.
> 
> COMMENT 1
> Section 2, Paragraph 1 states: "A particular OCSP server
>    may or may not be provided by the CA that issued the certificate
>    whose status is being queried and may or may provide a realtime
>    indication of the certificate status or a time delayed status
>    indication.".
> 
> The above should be changed to: "An OCSP Responder may or may not be
> issued an OCSP Responder certificate by the CA that issued the
> certificate whose status is being queried.  An OCSP Responder may
> provide pre-signed OCSP responses, OCSP responses freshly signed in
> response to an OCSP request, or a combination of the two."
> 
> COMMENT 2
> Section 2, Paragraph 4 states: "While the responder may apply heuristics
> such as using the signature
>    algorithm employed by the certificate issuer, such heuristics fail in
>    many common real-world situations where multiple signature algorithms
>    are employed:"
> 
> The whole premise of using certificate signing algorithm seems to be
> false.  It should be based on CRL signing.  Second 2 starting with
> paragraph 4 and including first set of bullets and short paragraph
> following the bullets should be revised as follows:
> 
> "While an OCSP Responder may apply rules such as using the signature
> algorithm employed by the CA for CRL signing, the rule may not work in
> the following circumstances:
> 
> o Algorithm used to sign the CRL may not be consistent with key pair
> being used by the OCSP Responder to sign responses."
> 
> I do not see how the remaining three bullets will be applicable.
> 
> COMMENT 3
> The following should be deleted from Section 2: "The last criterion is
> significant as it occurs frequently in real world PKI deployments and
> cannot be resolved through the information
>    available from in-band signalling using the RFC 2560 [RFC2560]
>    protocol without modification"
> 
> COMMENT 4
> Section 2 states "In addition, a system that employs a signature
> algorithm other than
>    the de-facto default is frequently doing so to achieve very specific
>    security properties that may not be captured by a heuristic
>    assumptuion designed to facilitate interoperability rather than
>    performance.  In particular:
> 
>    o  An implementation may intentionally employ an algorithm for
>       certificate status response that is less computationally demanding
>       than for signing the certificate itself, thus allowing for more
>       frequent certificate status validation.
> 
>    o  An implementation may intentionally wish to guard against the
>       possibility of a compromise resulting from a signature algorithm
>       compromise by employing two separate encryption algorithms."
> 
> This should be changed as follows: "An OCSP Responder may wish to employ
> different signature algorithm that the CRL signing algorithm for the
> following reasons:
> 
>    o  In order to generate pre-signed response more frequently or to
> meet the demand, the OCSP Responder may wish to employ a signing
> algorithm that is computationally less demanding for signature
> generation that the CRL signing algorithm
>       
>    o  A PKI may wish to guard against the possibility of a compromise
> resulting from a signature algorithm compromise by employing two
> separate signature algorithms for CRL and OCSP signing, thus allowing
> the relying parties to employ one mechanism or other for certificate
> status validation."
> 
> COMMENT 5
> Section 3 states: "A client MAY declare a preferred set of algorithms
> algorithms in a
>    request using the preferred signature algorithm extension."
> 
> Change it as follows: "A client MAY declare a preferred set of
> algorithms in a request using the preferred signature algorithms
> extension."
> 
> COMMENT 6
> Section 3, Should there be an indication these should be Algorithm
> Identifiers asserted in SIGNED MACRO and Signature field as opposed to
> those asserted in subject public key information?
> 
> COMMENT 7
> Section 3, Should it discuss what the impact is of the curves to be
> used?  Clients may not employ the curves in use by the server.
> 
> COMMENT 8
> Section states: "If a set of preferred signature algorithms is declared
> the client
>    MUST support each of the specified algorithms"
> 
> This should be changed to "If a set of preferred signature algorithms is
> specified by the client in the OCSP request, the client MUST support
> each of the specified algorithms."
> 
> COMMENT 9
> Section 4.1 and 4.2 need to stress that the OCSP Responder SHALL use
> signing algorithm whose cryptographic bit security is acceptable to the
> OCSP Responder.
> 
> COMMENT 10
> Section 4.1, 2nd choice should be CRL signing algorithm.  Thus, switch
> number 2 and 3.
> 
> COMMENT 11
> Section 7.2 should be revised as follows:
> 
>    "The mechanism to support client indication of preferred signature
>    algorithms is not protected against a man in the middle downgrade
>    attack.  This constraint is not considered to be a significant
>    security concern since the OCSP Responder MUST NOT sign OCSP
> Responses using weak algorithms even if requested by the client.  In
> addition, the client can reject OCSP responses that do not meet its own
> criteria for acceptable cryptographic security no matter what mechanism
> is used to determine the signing algorithm of the response.  This can be
> achieved using the DSSC I-D."
> 
> COMMENT 12
> The document needs additional editing.
> 
> Santosh Chokhani
> CygnaCom Solutions
> 
> "Questioning conventional wisdom is key to innovation"
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CBPPPC091654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 04:25:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CBPPEW091653; Wed, 12 Aug 2009 04:25:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CBPJB2091630 for <[e-mail]>; Wed, 12 Aug 2009 04:25:23 -0700 (MST) (envelope-from [e-mail])
X-IronPort-AV: E=Sophos;i="4.43,367,1246834800";  d="scan'208";a="16880109"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 12 Aug 2009 12:25:17 +0100
Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7CBPHQ8027852; Wed, 12 Aug 2009 12:25:17 +0100
Received: from GLKMS2105.GREENLNK.NET ([10.15.184.98]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Aug 2009 12:25:16 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: RE: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Date: Wed, 12 Aug 2009 12:25:16 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Thread-Index: Acoaobq/ssr8RbsWRVy+bZD3u15ExQAI3ZUAABk354A=
References: <[e-mail]> <[e-mail]>
From: "Skedd, Richard (UK)" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: "Rob Sherwood" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 Aug 2009 11:25:16.0452 (UTC) FILETIME=[91162E40:01CA1B3F]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Two comments on the points and responses below:

1.  Intent - I understand the value of clearance constraints if you are
going to include clearance attributes in PKCs but don't understand the
use case for the inclusion of clearance attributes in PKCs.  Perhaps you
could explain further.

3.  Clearances - I was interested in the comments regarding the
ClassList at item 3 below as the proposed list, to UK eyes, appears to
be completely arbitrary in scope and order.

I looked at RFC 3281 as suggested, this appears to just adopt
X.501-1993.  I could not find anything in X.501-1993 refering to
clearance.  RFC2634 and X.411-1997 refer to a very similar list as
Security Classifications:

  unmarked (0),
  unclassified (1),
  restricted (2),
  confidential (3),
  secret (4),
  top-secret (5)

But note that this is slightly different to that proposed in the draft
for Top Secret which is given as "topSecret".

At that point I gave up, if someone could enlighten me on where the list
came from and why it is still correct in 2009 I would be grateful.

I am also unsure of the value of a reserved list of text strings when
the application of the policyId field makes the actual meaning of all
entries in the ClassList policy specific.  There may also be problems
where a particular policy uses the values in the ClassList but in a
different hierarchical order.

Regards
 
Richard Skedd
IT Strategy Manager
T:    [phone] (vnet 7658 8034)
M:    [phone] (vnet 777118260)
 
BAE Systems plc
Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK
Registered in England & Wales No: 1470151 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: 11 August 2009 22:06
To: Rob Sherwood; [e-mail]
Subject: RE: TSCP Comments on
draft-ietf-pkix-authorityclearanceconstraints-02.txt


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.


Rob,

See responses in-line below. 

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Rob Sherwood
> Sent: Tuesday, August 11, 2009 12:35 PM
> To: [e-mail]
> Subject: TSCP Comments on
> draft-ietf-pkix-authorityclearanceconstraints-02.txt
> 
> 
> I am writing this message on behalf of the TSCP (http://www.tscp.org),

> to present our thoughts on the draft specification "Clearance 
> Attribute and Authority Clearance Constraints Certificate Extension"
> (draft-ietf-pkix-authorityclearanceconstraints-02.txt). Based on 
> review of the specification with our TSCP membership and discussion of

> the proposal, we wish to raise the following concerns regarding this
> specification:
> 
> 1. Firstly, there is no articulation of intent for use of this 
> standard in an implementation. It is unclear whether this is a 
> solution in search of a problem, or whether a use case has been 
> articulated. Given the close relationship between the CertiPath/TSCP 
> membership and the DoD, we are concerned that the unknown use case may

> impact the certificate profile or policy currently implemented within 
> the A&D Community.
> Accordingly, the A&D community represented in the TSCP would like to 
> have visibility regarding the intent of the standard.
[Santosh] Last two paragraphs of Section 1 of the I-D provide when
clearance constraints may be useful.  Once clearance constraint is used,
the relying parties need to enforce the intent of the clearance
constraint during certificate path validation.
 
> 
> 2. In many cases, individuals are forbidden to disclose the fact that 
> they hold a clearance. This proposal, if adopted for use in human 
> subscriber certificates, would either force violation of this rule or 
> create the need for individuals to maintain multiple certificates.
[Santosh] Section 9 of the I-D deals with how to use this information.
Please note that the I-D is not proposing that clearance or clearance
constraint will be a mandatory requirement for certificates.

> 
> 3. The list of clearances (ClassList) is incorrect. It appears to be a

> mixture of clearances and data sensitivity markings. This makes the 
> intent of the specification unclear, as it seems to be applicable to 
> both individuals and resource managers.
[Santosh] The classification list is from an existing vetted clearance
attribute defined in RFC 3281.

> 
> 4. Clearance level declarations are incomplete. Declaration of 
> clearance without investigation level (NACI, Poly, etc) and issuer 
> (DoD, Treasury,
> etc.) is insufficient to determine what resources may be shared.
[Santosh] The policyID object identifier in the clearance structure
defines the security policy to which the clearance relates.  That should
cover issuer and investigation level.  

> 
> 5. A specification of sensitivity/clearance in a certificate may be 
> useful for device certs or attribute certs, as a way to ensure that 
> networks of a certain classification are closed, and that 
> communication within and between them is protected, however the issues

> with the clearance list suggest that this proposal may not serve this 
> need.
[Santosh] The I-D deals with "subject".  Subject can be human or
non-human entity.

> 
> We are not necessarily opposed to the specification, but we would 
> first like to understand the details of the intent behind the 
> specification, and would like to discuss the issues with the draft 
> specification documented above.
> 
> Robert Sherwood
> Design Authority | Transglobal Secure Collaboration Authority 13530 
> Dulles Technology Dr, Ste 200, Herndon, VA 20171 PH
> +1.703.793.7705 (W) +1.703.362.2329 (M)
> 
> 
> 



********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7C3lmHh059339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 20:47:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7C3lmtj059338; Tue, 11 Aug 2009 20:47:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7C3lhVN059329 for <[e-mail]>; Tue, 11 Aug 2009 20:47:48 -0700 (MST) (envelope-from [e-mail])
Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipai.ntcif.telstra.com.au with ESMTP; 12 Aug 2009 13:47:42 +1000
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 961DFFF82 for <[e-mail]>; Wed, 12 Aug 2009 13:47:41 +1000 (EST)
Received: from wsmsg3707.srv.dir.telstra.com (wsmsg3707.in.telstra.com.au [172.49.40.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA08249 for <[e-mail]>; Wed, 12 Aug 2009 13:47:41 +1000 (EST)
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 12 Aug 2009 13:47:41 +1000
From: "Manger, James H" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Wed, 12 Aug 2009 13:47:40 +1000
Subject: RE: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt 
Thread-Topic: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt 
Thread-Index: Acoa0AMM/fOVberiQAWFofjzaxf/kwALlT8Q
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Q29tbWVudCBvbiBkcmFmdC1pZXRmLXBraXgtYXR0ci1jZXJ0LW1pbWUtdHlwZS0wMC50eHQNCg0K
VGhlcmUgaXNuJ3QgYSBjbGVhciBzdGF0ZW1lbnQgb2Ygd2hhdCB0aGUgY29udGVudCBpcyB3aGVu
IHRoZSBNSU1FIHR5cGUgaXMgYXBwbGljYXRpb24vcGtpeC1hdHRyLWNlcnQuDQpJIGFzc3VtZSBp
dCBpcyBhIHNpbmdsZSBERVItZW5jb2RlZCBhdHRyaWJ1dGUgY2VydGlmaWNhdGUgLS0gbm90IGEg
Y2hhaW4gb2YgQUNzLCBub3QgUEVNLWVuY29kZWQsIG5vdCBpbiBhIHBhY2thZ2UgdGhhdCBjYW4g
YWxzbyBob2xkIGFzc29jaWF0ZWQgcHVibGljLWtleSBjZXJ0cyBvciBDUkxzLiBBIHNlbnRlbmNl
IHN0YXRpbmcgdGhpcyB3b3VsZCBoZWxwLg0KDQpUeXBvOiB0aGUgb3BlbmluZyB3b3JkcyBvZiB0
aGUgSW50cm9kdWN0aW9uIGFyZSAiUkZDIDI1MjgiLCBidXQgc2hvdWxkIGJlICJSRkMgMjU4NSIu
DQoNCkphbWVzIE1hbmdlcg0KSmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbQ0KSWRlbnRp
dHkgYW5kIHNlY3VyaXR5IHRlYW0g4oCUIENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlIOKAlCBUZWxz
dHJhDQoNCi0tLS0tLS0tLS0NCkZyb206IG93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmcgW21h
aWx0bzpvd25lci1pZXRmLXBraXhAbWFpbC5pbWMub3JnXSBPbiBCZWhhbGYgT2YgSW50ZXJuZXQt
RHJhZnRzQGlldGYub3JnDQpTZW50OiBXZWRuZXNkYXksIDEyIEF1Z3VzdCAyMDA5IDc6MDAgQU0N
ClN1YmplY3Q6IEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1wa2l4LWF0dHItY2VydC1taW1lLXR5cGUt
MDAudHh0DQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s
aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0
ZW0gb2YgdGhlIFB1YmxpYy1LZXkgSW5mcmFzdHJ1Y3R1cmUgKFguNTA5KSBXb3JraW5nIEdyb3Vw
IG9mIHRoZSBJRVRGLg0KDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogVGhlIGFwcGxpY2F0
aW9uL3BraXgtYXR0ci1jZXJ0IENvbnRlbnQgVHlwZSBmb3IgQXR0cmlidXRlIENlcnRpZmljYXRl
cw0KICAgICAgICBBdXRob3IocykgICAgICAgOiBSLiBIb3VzbGV5DQogICAgICAgIEZpbGVuYW1l
ICAgICAgICA6IGRyYWZ0LWlldGYtcGtpeC1hdHRyLWNlcnQtbWltZS10eXBlLTAwLnR4dA0KICAg
ICAgICBQYWdlcyAgICAgICAgICAgOiAzDQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMDkt
MDgtMTENCg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBNSU1FIGNvbnRlbnQgdHlwZSBmb3Ig
dXNlIHdpdGggYXR0cmlidXRlDQpjZXJ0aWZpY2F0ZXMgYXMgZGVmaW5lZCBpbiBSRkMgMzI4MS4N
Cg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3Jn
L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtYXR0ci1jZXJ0LW1pbWUtdHlwZS0wMC50
eHQNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ
IGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KQmVsb3cgaXMgdGhl
IGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KaW1w
bGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBv
ZiB0aGUNCkludGVybmV0LURyYWZ0Lg0K



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7C0fQhg047333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 17:41:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7C0fQTm047331; Tue, 11 Aug 2009 17:41:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7C0fFlj047314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 17:41:17 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240826c6a7c0081700@[10.20.30.158]>
In-Reply-To: <p06240806c6a7a6c8f9e2@[10.84.131.96]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p06240806c6a7a6c8f9e2@[10.84.131.96]>
Date: Tue, 11 Aug 2009 17:41:14 -0700
To: Stephen Kent <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:54 PM -0400 8/11/09, Stephen Kent wrote:
>Since the 08 version has been posted and it addressed all of Sean's comments,
>I think it is time to initiate WGLC.  It starts tomorrow (8/12) and will end on 8/26.

Just to be clear: this is a *second* WGLC, or WGSLC, if you will.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BMsV7B041862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 15:54:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7BMsVQj041861; Tue, 11 Aug 2009 15:54:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BMsPHB041839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Aug 2009 15:54:31 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.131.96]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Mb0Ea-00038L-AI; Tue, 11 Aug 2009 18:54:24 -0400
Mime-Version: 1.0
Message-Id: <p06240806c6a7a6c8f9e2@[10.84.131.96]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 11 Aug 2009 18:54:21 -0400
To: Sean Turner <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Since the 08 version has been posted and it addressed all of Sean's comments,
I think it is time to initiate WGLC.  It starts tomorrow (8/12) and 
will end on 8/26.

Thanks,

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BMatwp040891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 15:36:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7BMatC1040890; Tue, 11 Aug 2009 15:36:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7BMas9Y040882 for <[e-mail]>; Tue, 11 Aug 2009 15:36:54 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 60657 invoked from network); 11 Aug 2009 22:36:53 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.231.126.205 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 11 Aug 2009 22:36:53 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: IhjL94EVM1mFuiFGIKsEFrNAQuDZ_UCethhQDlYG9gkG2XXbCZenieXrUWZInYNr_GaUhJKVbkZSeJT7IBN2ptf94tjRu9yZ98BYb1WbX2ZnzqNGyM_zI4YzAwhTYDAcw0MxfrNDJtddhAa.Mqp.k8A.AI2hrDkO6aLr6regWG6NjoH7tkjV_E7hBrdJn4jbLzGec0DNNecflg9j90HEdWr8t3Z.JuHwyyN1zxyimRtyzVcLtCHK1S6gQ5W.kx.2Rbv4GGu1yxAwVHDaCHDRwfAdEGyRELti3yaeeD4wggD5Ph5xYWdQbHTZ7YKh5RD4wk1Jboh9hX.Pe6aJCLodqyZlB4srgr99QgaRpg--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Tue, 11 Aug 2009 18:36:52 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The -08 version addresses all of my comments.

spt

Sean Turner wrote:
> 
> I've got some comments on draft-ietf-pkix-sha2-dsa-ecdsa.
> 
> The introduction states that the document specifies values for
> signatureValue, signatureAlgorithm, and signature.  Section 2 includes
> hash algorithm OIDs.  None of these hash OIDs ever appear in one of
> these fields.  We should either a) delete section 2 (not what I suspect
> we want) b) change the abstract/intro to indicate that we're also
> specifying hash algorithms. May I suggest the following changes to the
> abstract/intro:
> 
> b1) No references in abstract: r/This document updates RFC 3279 [RFC
> 3279]/This document updates RFC 3279
> 
> b2) Add the following to the end of the abstract and in the intro: This 
> document also identifies the SHA2 family of one-way hash functions for 
> use in the Internet X.509 PKI.
> 
> b3) Add a new final intro paragraph to say explicitly what got updated
> and to indicate other sections in 3279 have been updated by RFC 5480:
> This document updates RFC 3279 [RFC3279] sections 2.1, 2.2.2, and 2.2.3. 
>  Note that RFC 5480 [RFC 5480] updates sections 2.3.5 and 5, and the 
> ASN.1 module.
> 
> Section 3: r/This section identifies OIDs for DSA and ECDSA with
> SHA-224, SHA-256, SHA-384, and SHA-512./This section identifies OIDs for
> DSA with SHA-224 and SHA-256 as well as ECDSA with SHA-SHA-224, SHA-256,
> SHA-384, and SHA-512.
> 
> Section 3.2: RFC 5480 updates the entire 3279 ASN.1 module so I
> think we should point there for ECDSA signature values.  r/Encoding
> rules for ECDSA signature values are specified in [RFC 3279]/Encoding
> rules for ECDSA signature values are specified in [RFC 5480].
> 
> Section 4: I think we should delete the pseudo ASN.1 module because it's
> not a valid ASN.1 module, the SHA2 OIDs are already in RFC 4055 ASN.1
> module, and DSA/ECDSA OIDs are already in the RFC 5480 ASN.1 module (the
> RFC 5480 imports the SHA2 OIDS from RFC 4055).  I suggest we replace the
> entire section with the following: "The SHA2 family of OIDs are in the
> RFC 4055 [RFC 4055] ASN.1 module and the OIDs for DSA with SHA-224 and
> SHA-256 as well as ECDSA with SHA-SHA-224, SHA-256, SHA-384, and SHA-512
> are defined in RFC 5480 [RFC 5480] ASN.1 module."
> 
> Add references to include RFC 4055 and RFC 5480.
> 
> spt
> 
> [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Public-Key Infrastructure (X.509) 
>> Working Group of the IETF.
>>
>>
>>     Title           : Internet X.509 Public Key Infrastructure: 
>> Additional Algorithms and Identifiers for DSA and ECDSA
>>     Author(s)       : Q. Dang
>>     Filename        : draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
>>     Pages           : 9
>>     Date            : 2009-08-04
>>
>> This document updates RFC 3279 [RFC 3279] to specify algorithm   
>> identifiers and ASN.1 encoding rules for the Digital Signature   
>> Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm   
>> (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384   or 
>> SHA-512 as hashing algorithm. This specification applies to   the 
>> Internet X.509 Public Key infrastructure (PKI) when digital   
>> signatures are used to sign certificates and certificate   revocation 
>> lists(CRLs).
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
> 
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BL6FLe036480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 14:06:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7BL6F7f036479; Tue, 11 Aug 2009 14:06:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BL66u1036472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Aug 2009 14:06:14 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO p03c11o143.symantecmail.net) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 64dd18a4.3099360176.115560.00-503.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Tue, 11 Aug 2009 15:06:14 -0600 (MDT)
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id e3dd18a4.3719908272.115554.00-003.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Tue, 11 Aug 2009 15:06:06 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Date: Tue, 11 Aug 2009 17:06:02 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
thread-index: Acoaobq/ssr8RbsWRVy+bZD3u15ExQAI3ZUA
References: <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Rob Sherwood" <[e-mail]>, <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rob,

See responses in-line below.=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Rob Sherwood
> Sent: Tuesday, August 11, 2009 12:35 PM
> To: [e-mail]
> Subject: TSCP Comments on=20
> draft-ietf-pkix-authorityclearanceconstraints-02.txt
>=20
>=20
> I am writing this message on behalf of the TSCP=20
> (http://www.tscp.org), to present our thoughts on the draft=20
> specification "Clearance Attribute and Authority Clearance=20
> Constraints Certificate Extension"
> (draft-ietf-pkix-authorityclearanceconstraints-02.txt). Based=20
> on review of the specification with our TSCP membership and=20
> discussion of the proposal, we wish to raise the following=20
> concerns regarding this
> specification:
>=20
> 1. Firstly, there is no articulation of intent for use of=20
> this standard in an implementation. It is unclear whether=20
> this is a solution in search of a problem, or whether a use=20
> case has been articulated. Given the close relationship=20
> between the CertiPath/TSCP membership and the DoD, we are=20
> concerned that the unknown use case may impact the=20
> certificate profile or policy currently implemented within=20
> the A&D Community.
> Accordingly, the A&D community represented in the TSCP would=20
> like to have visibility regarding the intent of the standard.
[Santosh] Last two paragraphs of Section 1 of the I-D provide when
clearance constraints may be useful.  Once clearance constraint is used,
the relying parties need to enforce the intent of the clearance
constraint during certificate path validation.
=20
>=20
> 2. In many cases, individuals are forbidden to disclose the=20
> fact that they hold a clearance. This proposal, if adopted=20
> for use in human subscriber certificates, would either force=20
> violation of this rule or create the need for individuals to=20
> maintain multiple certificates.
[Santosh] Section 9 of the I-D deals with how to use this information.
Please note that the I-D is not proposing that clearance or clearance
constraint will be a mandatory requirement for certificates.

>=20
> 3. The list of clearances (ClassList) is incorrect. It=20
> appears to be a mixture of clearances and data sensitivity=20
> markings. This makes the intent of the specification unclear,=20
> as it seems to be applicable to both individuals and resource=20
> managers.
[Santosh] The classification list is from an existing vetted clearance
attribute defined in RFC 3281.

>=20
> 4. Clearance level declarations are incomplete. Declaration=20
> of clearance without investigation level (NACI, Poly, etc)=20
> and issuer (DoD, Treasury,
> etc.) is insufficient to determine what resources may be shared.
[Santosh] The policyID object identifier in the clearance structure
defines the security policy to which the clearance relates.  That should
cover issuer and investigation level. =20

>=20
> 5. A specification of sensitivity/clearance in a certificate=20
> may be useful for device certs or attribute certs, as a way=20
> to ensure that networks of a certain classification are=20
> closed, and that communication within and between them is=20
> protected, however the issues with the clearance list suggest=20
> that this proposal may not serve this need.
[Santosh] The I-D deals with "subject".  Subject can be human or
non-human entity.

>=20
> We are not necessarily opposed to the specification, but we=20
> would first like to understand the details of the intent=20
> behind the specification, and would like to discuss the=20
> issues with the draft specification documented above.
>=20
> Robert Sherwood
> Design Authority | Transglobal Secure Collaboration Authority=20
> 13530 Dulles Technology Dr, Ste 200, Herndon, VA 20171 PH=20
> +1.703.793.7705 (W) +1.703.362.2329 (M)
>=20
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BL06fB036006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 14:00:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7BL06aO036005; Tue, 11 Aug 2009 14:00:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BL05kW035998 for <[e-mail]>; Tue, 11 Aug 2009 14:00:06 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 753843A6A9E; Tue, 11 Aug 2009 14:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 11 Aug 2009 14:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.


	Title           : The application/pkix-attr-cert Content Type for Attribute Certificates
	Author(s)       : R. Housley
	Filename        : draft-ietf-pkix-attr-cert-mime-type-00.txt
	Pages           : 3
	Date            : 2009-08-11

This document specifies a MIME content type for use with attribute
certificates as defined in RFC 3281.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-attr-cert-mime-type-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-attr-cert-mime-type-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BJUKY3029595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 12:30:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7BJUKIN029594; Tue, 11 Aug 2009 12:30:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BJU8KJ029576 for <[e-mail]>; Tue, 11 Aug 2009 12:30:18 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id A0BA53A6FE9; Tue, 11 Aug 2009 12:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 11 Aug 2009 12:30:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.


	Title           : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
	Author(s)       : Q. Dang
	Filename        : draft-ietf-pkix-sha2-dsa-ecdsa-08.txt
	Pages           : 8
	Date            : 2009-08-11

This document updates RFC 3279 to specify algorithm 
  identifiers and ASN.1 encoding rules for the Digital Signature 
  Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm 
  (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 
  or SHA-512 as hashing algorithm. This specification applies to 
  the Internet X.509 Public Key infrastructure (PKI) when digital 
  signatures are used to sign certificates and certificate 
  revocation lists(CRLs).This document also identifies all four SHA2 
  hash algorithms for use in the Internet X.509 PKI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sha2-dsa-ecdsa-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BH7ba4018468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 10:07:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7BH7bWc018467; Tue, 11 Aug 2009 10:07:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n7BH7QZx018458 for <[e-mail]>; Tue, 11 Aug 2009 10:07:36 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 95020 invoked from network); 11 Aug 2009 17:07:26 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.231.126.205 with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 11 Aug 2009 17:07:25 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: 0_MSaegVM1kY5iqtZcXoqOdVeMOYmqMZI6cgQYaQTeLZegp1.lPE84pmkw7oWPgWtjMgBbWhXLKDuiQ.s3iAiWRDxpotHg.xrlHeZjj8UK3VaditHETIpm9wZtfxk7YFa55Wkz2PCM00yEvEZ6eB3FwiHWFj1EpuupcGJcMB_VPdhzIypvi8rrVZdgxa5REGYGILoQgHPr6m2WxPOBf9n0vZK.5MvRmGYDy_jxzZXQzdWk74_w1EfXtOlyR3z3b7Qa6r7CYQFA9O9.Zqp.YXd3gDAfupg79SlSbSSbFhrtfM9qnOUhnKzd5MbfJPHG_.vk2UDn0WFLxBlnLTCYyk37baPcb8QNg_k1.9SQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Tue, 11 Aug 2009 13:07:25 -0400
From: Sean Turner <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've got some comments on draft-ietf-pkix-sha2-dsa-ecdsa.

The introduction states that the document specifies values for
signatureValue, signatureAlgorithm, and signature.  Section 2 includes
hash algorithm OIDs.  None of these hash OIDs ever appear in one of
these fields.  We should either a) delete section 2 (not what I suspect
we want) b) change the abstract/intro to indicate that we're also
specifying hash algorithms. May I suggest the following changes to the
abstract/intro:

b1) No references in abstract: r/This document updates RFC 3279 [RFC
3279]/This document updates RFC 3279

b2) Add the following to the end of the abstract and in the intro: This 
document also identifies the SHA2 family of one-way hash functions for 
use in the Internet X.509 PKI.

b3) Add a new final intro paragraph to say explicitly what got updated
and to indicate other sections in 3279 have been updated by RFC 5480:
This document updates RFC 3279 [RFC3279] sections 2.1, 2.2.2, and 2.2.3. 
  Note that RFC 5480 [RFC 5480] updates sections 2.3.5 and 5, and the 
ASN.1 module.

Section 3: r/This section identifies OIDs for DSA and ECDSA with
SHA-224, SHA-256, SHA-384, and SHA-512./This section identifies OIDs for
DSA with SHA-224 and SHA-256 as well as ECDSA with SHA-SHA-224, SHA-256,
SHA-384, and SHA-512.

Section 3.2: RFC 5480 updates the entire 3279 ASN.1 module so I
think we should point there for ECDSA signature values.  r/Encoding
rules for ECDSA signature values are specified in [RFC 3279]/Encoding
rules for ECDSA signature values are specified in [RFC 5480].

Section 4: I think we should delete the pseudo ASN.1 module because it's
not a valid ASN.1 module, the SHA2 OIDs are already in RFC 4055 ASN.1
module, and DSA/ECDSA OIDs are already in the RFC 5480 ASN.1 module (the
RFC 5480 imports the SHA2 OIDS from RFC 4055).  I suggest we replace the
entire section with the following: "The SHA2 family of OIDs are in the
RFC 4055 [RFC 4055] ASN.1 module and the OIDs for DSA with SHA-224 and
SHA-256 as well as ECDSA with SHA-SHA-224, SHA-256, SHA-384, and SHA-512
are defined in RFC 5480 [RFC 5480] ASN.1 module."

Add references to include RFC 4055 and RFC 5480.

spt

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 
> 	Title           : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
> 	Author(s)       : Q. Dang
> 	Filename        : draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
> 	Pages           : 9
> 	Date            : 2009-08-04
> 
> This document updates RFC 3279 [RFC 3279] to specify algorithm 
>   identifiers and ASN.1 encoding rules for the Digital Signature 
>   Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm 
>   (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 
>   or SHA-512 as hashing algorithm. This specification applies to 
>   the Internet X.509 Public Key infrastructure (PKI) when digital 
>   signatures are used to sign certificates and certificate 
>   revocation lists(CRLs).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BGXrFw016284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 09:33:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7BGXqW4016283; Tue, 11 Aug 2009 09:33:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from Netmail1.exostar.com (netmail1.exostar.com [69.50.101.14]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7BGXjRH016271 for <[e-mail]>; Tue, 11 Aug 2009 09:33:52 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Date: Tue, 11 Aug 2009 12:35:25 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Thread-Index: Acoaobq/ssr8RbsWRVy+bZD3u15ExQ==
From: "Rob Sherwood" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am writing this message on behalf of the TSCP (http://www.tscp.org),
to present our thoughts on the draft specification "Clearance Attribute
and Authority Clearance Constraints Certificate Extension"
(draft-ietf-pkix-authorityclearanceconstraints-02.txt). Based on review
of the specification with our TSCP membership and discussion of the
proposal, we wish to raise the following concerns regarding this
specification:

1. Firstly, there is no articulation of intent for use of this standard
in an implementation. It is unclear whether this is a solution in search
of a problem, or whether a use case has been articulated. Given the
close relationship between the CertiPath/TSCP membership and the DoD, we
are concerned that the unknown use case may impact the certificate
profile or policy currently implemented within the A&D Community.
Accordingly, the A&D community represented in the TSCP would like to
have visibility regarding the intent of the standard.=20

2. In many cases, individuals are forbidden to disclose the fact that
they hold a clearance. This proposal, if adopted for use in human
subscriber certificates, would either force violation of this rule or
create the need for individuals to maintain multiple certificates.

3. The list of clearances (ClassList) is incorrect. It appears to be a
mixture of clearances and data sensitivity markings. This makes the
intent of the specification unclear, as it seems to be applicable to
both individuals and resource managers.

4. Clearance level declarations are incomplete. Declaration of clearance
without investigation level (NACI, Poly, etc) and issuer (DoD, Treasury,
etc.) is insufficient to determine what resources may be shared.

5. A specification of sensitivity/clearance in a certificate may be
useful for device certs or attribute certs, as a way to ensure that
networks of a certain classification are closed, and that communication
within and between them is protected, however the issues with the
clearance list suggest that this proposal may not serve this need.

We are not necessarily opposed to the specification, but we would first
like to understand the details of the intent behind the specification,
and would like to discuss the issues with the draft specification
documented above.

Robert Sherwood=20
Design Authority | Transglobal Secure Collaboration Authority
13530 Dulles Technology Dr, Ste 200, Herndon, VA 20171
PH +1.703.793.7705 (W) +1.703.362.2329 (M)




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7AG4Wvr010883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2009 09:04:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7AG4W7e010882; Mon, 10 Aug 2009 09:04:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7AG4L52010871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 10 Aug 2009 09:04:31 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id f05408a4.3089910704.91144.00-013.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Mon, 10 Aug 2009 10:04:31 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Date: Mon, 10 Aug 2009 12:04:17 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt
thread-index: AcoZ1DbkFeo2XmhRRhq2Obxb6zRS1Q==
From: "Santosh Chokhani" <[e-mail]>
To: "ietf-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I had sent the following comments and Recommendations for the I-D to
Stefan last week.  This may of interest to others.

COMMENT 1
Section 2, Paragraph 1 states: "A particular OCSP server
   may or may not be provided by the CA that issued the certificate
   whose status is being queried and may or may provide a realtime
   indication of the certificate status or a time delayed status
   indication.".

The above should be changed to: "An OCSP Responder may or may not be
issued an OCSP Responder certificate by the CA that issued the
certificate whose status is being queried.  An OCSP Responder may
provide pre-signed OCSP responses, OCSP responses freshly signed in
response to an OCSP request, or a combination of the two."

COMMENT 2
Section 2, Paragraph 4 states: "While the responder may apply heuristics
such as using the signature
   algorithm employed by the certificate issuer, such heuristics fail in
   many common real-world situations where multiple signature algorithms
   are employed:"

The whole premise of using certificate signing algorithm seems to be
false.  It should be based on CRL signing.  Second 2 starting with
paragraph 4 and including first set of bullets and short paragraph
following the bullets should be revised as follows:

"While an OCSP Responder may apply rules such as using the signature
algorithm employed by the CA for CRL signing, the rule may not work in
the following circumstances:

o Algorithm used to sign the CRL may not be consistent with key pair
being used by the OCSP Responder to sign responses."

I do not see how the remaining three bullets will be applicable.

COMMENT 3
The following should be deleted from Section 2: "The last criterion is
significant as it occurs frequently in real world PKI deployments and
cannot be resolved through the information
   available from in-band signalling using the RFC 2560 [RFC2560]
   protocol without modification"

COMMENT 4
Section 2 states "In addition, a system that employs a signature
algorithm other than
   the de-facto default is frequently doing so to achieve very specific
   security properties that may not be captured by a heuristic
   assumptuion designed to facilitate interoperability rather than
   performance.  In particular:

   o  An implementation may intentionally employ an algorithm for
      certificate status response that is less computationally demanding
      than for signing the certificate itself, thus allowing for more
      frequent certificate status validation.

   o  An implementation may intentionally wish to guard against the
      possibility of a compromise resulting from a signature algorithm
      compromise by employing two separate encryption algorithms."

This should be changed as follows: "An OCSP Responder may wish to employ
different signature algorithm that the CRL signing algorithm for the
following reasons:

   o  In order to generate pre-signed response more frequently or to
meet the demand, the OCSP Responder may wish to employ a signing
algorithm that is computationally less demanding for signature
generation that the CRL signing algorithm
     =20
   o  A PKI may wish to guard against the possibility of a compromise
resulting from a signature algorithm compromise by employing two
separate signature algorithms for CRL and OCSP signing, thus allowing
the relying parties to employ one mechanism or other for certificate
status validation."

COMMENT 5
Section 3 states: "A client MAY declare a preferred set of algorithms
algorithms in a
   request using the preferred signature algorithm extension."

Change it as follows: "A client MAY declare a preferred set of
algorithms in a request using the preferred signature algorithms
extension."

COMMENT 6
Section 3, Should there be an indication these should be Algorithm
Identifiers asserted in SIGNED MACRO and Signature field as opposed to
those asserted in subject public key information?

COMMENT 7
Section 3, Should it discuss what the impact is of the curves to be
used?  Clients may not employ the curves in use by the server.

COMMENT 8
Section states: "If a set of preferred signature algorithms is declared
the client
   MUST support each of the specified algorithms"

This should be changed to "If a set of preferred signature algorithms is
specified by the client in the OCSP request, the client MUST support
each of the specified algorithms."

COMMENT 9
Section 4.1 and 4.2 need to stress that the OCSP Responder SHALL use
signing algorithm whose cryptographic bit security is acceptable to the
OCSP Responder.

COMMENT 10
Section 4.1, 2nd choice should be CRL signing algorithm.  Thus, switch
number 2 and 3.

COMMENT 11
Section 7.2 should be revised as follows:

   "The mechanism to support client indication of preferred signature
   algorithms is not protected against a man in the middle downgrade
   attack.  This constraint is not considered to be a significant
   security concern since the OCSP Responder MUST NOT sign OCSP
Responses using weak algorithms even if requested by the client.  In
addition, the client can reject OCSP responses that do not meet its own
criteria for acceptable cryptographic security no matter what mechanism
is used to determine the signing algorithm of the response.  This can be
achieved using the DSSC I-D."

COMMENT 12
The document needs additional editing.

Santosh Chokhani
CygnaCom Solutions

"Questioning conventional wisdom is key to innovation"



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n79DWIqg019941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 06:32:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n79DWIbF019939; Sun, 9 Aug 2009 06:32:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n79DWDAQ019923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 06:32:14 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240815c6a48007e9e2@[10.20.30.158]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Sun, 9 Aug 2009 06:32:13 -0700
To: [e-mail], Sean Turner <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: SMIME report (IETF 75)
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From the S/MIME WG mailing list:

At 12:55 PM +0100 8/9/09, John Larmouth wrote:
>"I have reviewed draft-ietf-smime-new-asn1-05.txt and	also draft-ietf-pkix-new-asn1-05.txt
>because the smime IMPORTS from that. Everything seems to be OK. I have only one comment about
>draft-ietf-pkix-new-asn1-05.txt: in three places in OID values "member-body" is misspelled
>as "memberBody".

Got it. This will be fixed in draft-ietf-pkix-new-asn1-06.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74JU8wI008902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2009 12:30:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n74JU8e4008901; Tue, 4 Aug 2009 12:30:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74JU4bO008892 for <[e-mail]>; Tue, 4 Aug 2009 12:30:05 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 679923A6AF7; Tue,  4 Aug 2009 12:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue,  4 Aug 2009 12:30:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.


	Title           : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
	Author(s)       : Q. Dang
	Filename        : draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
	Pages           : 9
	Date            : 2009-08-04

This document updates RFC 3279 [RFC 3279] to specify algorithm 
  identifiers and ASN.1 encoding rules for the Digital Signature 
  Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm 
  (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 
  or SHA-512 as hashing algorithm. This specification applies to 
  the Internet X.509 Public Key infrastructure (PKI) when digital 
  signatures are used to sign certificates and certificate 
  revocation lists(CRLs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sha2-dsa-ecdsa-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74Ef1Ip087255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2009 07:41:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n74Ef1WA087254; Tue, 4 Aug 2009 07:41:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74EerlY087232 for <[e-mail]>; Tue, 4 Aug 2009 07:41:01 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-105.bbn.com ([128.89.89.105]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1MYKG1-0008Cd-Ef; Tue, 04 Aug 2009 09:40:49 -0400
Mime-Version: 1.0
Message-Id: <p06240806c69df525a82d@[128.89.89.105]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 4 Aug 2009 10:27:17 -0400
To: "Kemp, David P." <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Embedded certificate image
Cc: "ietf-pkix" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:46 PM -0400 8/3/09, Kemp, David P. wrote:
>If a CA were going to accept user input to an image composed by the CA,
>then the composition process can provide confounding data by doing more
>than just "inserting a customer-provided graphic into a [known] template
>provided by the CA".  The Security Considerations section could
>recommend steganographic techniques for unpredictably modifying the
>image in perceptually-insignificant ways, such as by adding noise to the
>image data and/or inserting random tags in image formats for which tags
>are defined.
>

David,

I think a CA-selected, random prefix may be a better choice here. An 
organization may be very "attached" to its logo and not want any form 
of manipulation.  In many (most?) cases I expect the organization to 
provide the artwork in precisely the form they will want it to be 
displayed. It would be much easier for a CA to just generate random 
bit string and insert in into a data structure used to convey the 
image, rather than having to be able to watermark the image in some 
fahsion.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74DavMb080815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2009 06:36:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n74DavLp080814; Tue, 4 Aug 2009 06:36:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74Dal2P080803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 4 Aug 2009 06:36:56 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id CAA7710041596; Tue,  4 Aug 2009 14:36:46 +0100 (IST)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sroypBsq6kKa; Tue,  4 Aug 2009 14:36:46 +0100 (IST)
Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 6742E10040765; Tue,  4 Aug 2009 14:36:45 +0100 (IST)
Message-ID: <[e-mail]>
Date: Tue, 04 Aug 2009 14:36:46 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "Kemp, David P." <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Embedded certificate image
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Another -1 to the complexity here.

There are folks who try to spot images that contain stego
stuff and flag those as suspect. I guess we don't want
certs to start showing up in such lists (or maybe that'd
be amusing;-)

S.

Santosh Chokhani wrote:
> Dave,
> 
> What you propose and Tom proposed seem to work from security viewpoint.
> I do not know the impact on processing.  I assume some noise in graphics
> should not impact it. 
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Kemp, David P.
>> Sent: Monday, August 03, 2009 4:47 PM
>> To: ietf-pkix
>> Subject: RE: Embedded certificate image
>>
>>
>> If a CA were going to accept user input to an image composed 
>> by the CA, then the composition process can provide 
>> confounding data by doing more than just "inserting a 
>> customer-provided graphic into a [known] template provided by 
>> the CA".  The Security Considerations section could recommend 
>> steganographic techniques for unpredictably modifying the 
>> image in perceptually-insignificant ways, such as by adding 
>> noise to the image data and/or inserting random tags in image 
>> formats for which tags are defined.
>>
>>
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]]
>> On Behalf Of Santosh Chokhani
>> Sent: Monday, August 03, 2009 10:39 AM
>> To: Timothy J. Miller; Tom Gindin
>> Cc: Stefan Santesson; ietf-pkix
>> Subject: RE: Embedded certificate image
>>
>>
>> Tim,
>>
>> Depending on the nature of collision, randomly reordering 
>> extensions may not help at all or may not provide 
>> sufficiently low probability of successful collision.
>>
>>> -----Original Message-----
>>> From: Timothy J. Miller [mailto:[e-mail]]
>>> Sent: Monday, August 03, 2009 8:51 AM
>>> To: Tom Gindin
>>> Cc: Stefan Santesson; ietf-pkix; Santosh Chokhani
>>> Subject: Re: Embedded certificate image
>>>
>>> Tom Gindin wrote:
>>>>         Stefan:
>>>>
>>>>         While it is unreasonable to dictate what a CA can 
>> accept, I 
>>>> think that the Security Considerations section should say 
>> something
>>>> like: "the information about the certificate subject
>>> contained in the
>>>> image SHOULD NOT include any graphic supplied by the
>>> applicant".  The
>>>> "tumor" construct which we saw in MD5 collisions could be
>>> placed into
>>>> such a graphic.  Thus if a CA were to construct a graphic
>>> by inserting
>>>> a customer-provided graphic into a template provided by 
>> the CA, it 
>>>> would be subject to the same attacks as MD5 certificates 
>> have been, 
>>>> but it would not be evident from the certificate syntax.
>>> I'd rather require the CA to include a confounder in the 
>> prefix than 
>>> restrict the CAs ability to accept input.  There are 
>> multiple places 
>>> where a CA can do this; serial number being one (but more or less 
>>> difficult for some PKIs to implement), random-skew validity periods 
>>> being another.  To confound a prefix using this extension, random 
>>> reordering extensions is enough.
>>>
>>> -- Tim
>>>
>>
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74DV8Yf080400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2009 06:31:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n74DV8dF080398; Tue, 4 Aug 2009 06:31:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail67.messagelabs.com (mail67.messagelabs.com [193.109.254.83]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n74DUudU080374 for <[e-mail]>; Tue, 4 Aug 2009 06:31:07 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-67.messagelabs.com!1249392654!29669821!1
X-StarScan-Version: 6.1.2; banners=.,-,-
X-Originating-IP: [195.92.40.48]
Received: (qmail 28993 invoked from network); 4 Aug 2009 13:30:54 -0000
Received: from gateway-201.energis.gsi.gov.uk (HELO mx.hosting-e.gsi.gov.uk) (195.92.40.48) by server-12.tower-67.messagelabs.com with SMTP; 4 Aug 2009 13:30:54 -0000
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-5.tower-185.messagelabs.com!1249333943!42068140!1
X-StarScan-Version: 6.0.0; banners=-,-,gchq.gsi.gov.uk
X-Originating-IP: [192.245.12.227]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Embedded certificate image
Date: Mon, 3 Aug 2009 16:46:41 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Embedded certificate image
Thread-Index: AcoUOQZju1e67kdTSKWwyKSH/3Yj0AADvp3wAAxRyOA=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "ietf-pkix" <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2009 20:39:05.0328 (UTC) FILETIME=[71528700:01CA147A]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Source: Internet
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If=20a=20CA=20were=20going=20to=20accept=20user=20input=20to=20an=20image=20=
composed=20by=20the=20CA,
then=20the=20composition=20process=20can=20provide=20confounding=20data=20=
by=20doing=20more
than=20just=20"inserting=20a=20customer-provided=20graphic=20into=20a=20[k=
nown]=20template
provided=20by=20the=20CA".=20=20The=20Security=20Considerations=20section=20=
could
recommend=20steganographic=20techniques=20for=20unpredictably=20modifying=20=
the
image=20in=20perceptually-insignificant=20ways,=20such=20as=20by=20adding=20=
noise=20to=20the
image=20data=20and/or=20inserting=20random=20tags=20in=20image=20formats=20=
for=20which=20tags
are=20defined.


-----Original=20Message-----
From:=[e-mail]=20[mailto:[e-mail]=
g]
On=20Behalf=20Of=20Santosh=20Chokhani
Sent:=20Monday,=20August=2003,=202009=2010:39=20AM
To:=20Timothy=20J.=20Miller;=20Tom=20Gindin
Cc:=20Stefan=20Santesson;=20ietf-pkix
Subject:=20RE:=20Embedded=20certificate=20image


Tim,

Depending=20on=20the=20nature=20of=20collision,=20randomly=20reordering=20=
extensions=20may
not=20help=20at=20all=20or=20may=20not=20provide=20sufficiently=20low=20pr=
obability=20of
successful=20collision.

>=20-----Original=20Message-----
>=20From:=20Timothy=20J.=20Miller=20[mailto:[e-mail]]=20
>=20Sent:=20Monday,=20August=2003,=202009=208:51=20AM
>=20To:=20Tom=20Gindin
>=20Cc:=20Stefan=20Santesson;=20ietf-pkix;=20Santosh=20Chokhani
>=20Subject:=20Re:=20Embedded=20certificate=20image
>=20
>=20Tom=20Gindin=20wrote:
>=20>=20=20=20=20=20=20=20=20=20Stefan:
>=20>=20
>=20>=20=20=20=20=20=20=20=20=20While=20it=20is=20unreasonable=20to=20dict=
ate=20what=20a=20CA=20can=20accept,=20I=20
>=20>=20think=20that=20the=20Security=20Considerations=20section=20should=20=
say=20something=20
>=20>=20like:=20"the=20information=20about=20the=20certificate=20subject=20=

>=20contained=20in=20the=20
>=20>=20image=20SHOULD=20NOT=20include=20any=20graphic=20supplied=20by=20t=
he=20
>=20applicant".=20=20The=20
>=20>=20"tumor"=20construct=20which=20we=20saw=20in=20MD5=20collisions=20c=
ould=20be=20
>=20placed=20into=20
>=20>=20such=20a=20graphic.=20=20Thus=20if=20a=20CA=20were=20to=20construc=
t=20a=20graphic=20
>=20by=20inserting=20
>=20>=20a=20customer-provided=20graphic=20into=20a=20template=20provided=20=
by=20the=20CA,=20it=20
>=20>=20would=20be=20subject=20to=20the=20same=20attacks=20as=20MD5=20cert=
ificates=20have=20been,=20
>=20>=20but=20it=20would=20not=20be=20evident=20from=20the=20certificate=20=
syntax.
>=20
>=20I'd=20rather=20require=20the=20CA=20to=20include=20a=20confounder=20in=
=20the=20
>=20prefix=20than=20restrict=20the=20CAs=20ability=20to=20accept=20input.=20=
=20There=20
>=20are=20multiple=20places=20where=20a=20CA=20can=20do=20this;=20serial=20=
number=20
>=20being=20one=20(but=20more=20or=20less=20difficult=20for=20some=20PKIs=20=
to=20
>=20implement),=20random-skew=20validity=20periods=20being=20another.=20=20=
To=20
>=20confound=20a=20prefix=20using=20this=20extension,=20random=20reorderin=
g=20
>=20extensions=20is=20enough.
>=20
>=20--=20Tim
>=20


This=20email=20was=20received=20from=20the=20INTERNET=20and=20scanned=20by=
=20the=20Government=20Secure=20Intranet=20anti-virus=20service=20supplied=20=
by=20Cable&Wireless=20in=20partnership=20with=20MessageLabs.=20(CCTM=20Cer=
tificate=20Number=202007/11/0032.)=20In=20case=20of=20problems,=20please=20=
call=20your=20organisation=92s=20IT=20Helpdesk.=20
Communications=20via=20the=20GSi=20may=20be=20automatically=20logged,=20mo=
nitored=20and/or=20recorded=20for=20legal=20purposes.


**************************************************************************=
**
Communications=20with=20GCHQ=20may=20be=20monitored=20and/or=20recorded=20=

for=20system=20efficiency=20and=20other=20lawful=20purposes.=20Any=20views=
=20or=20
opinions=20expressed=20in=20this=20e-mail=20do=20not=20necessarily=20refle=
ct=20GCHQ=20
policy.=20=20This=20email,=20and=20any=20attachments,=20is=20intended=20fo=
r=20the=20
attention=20of=20the=20addressee(s)=20only.=20Its=20unauthorised=20use,=20=

disclosure,=20storage=20or=20copying=20is=20not=20permitted.=20=20If=20you=
=20are=20not=20the
intended=20recipient,=20please=20notify=[e-mail].=20=20=


This=20information=20is=20exempt=20from=20disclosure=20under=20the=20Freed=
om=20of=20
Information=20Act=202000=20and=20may=20be=20subject=20to=20exemption=20und=
er
other=20UK=20information=20legislation.=20Refer=20disclosure=20requests=20=
to=20
GCHQ=20on=2001242=20221491=20ext=2030306=20(non-secure)=20or=20email
[e-mail]

**************************************************************************=
**


______________________________________________________________________
This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20
______________________________________________________________________



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74CcxKA075314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2009 05:38:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n74CcxK8075313; Tue, 4 Aug 2009 05:38:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74Ccq9Z075300 for <[e-mail]>; Tue, 4 Aug 2009 05:38:58 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Embedded certificate image
Date: Tue, 4 Aug 2009 08:37:22 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Embedded certificate image
Thread-Index: AcoUOQZju1e67kdTSKWwyKSH/3Yj0AADvp3wAAxRyOAAATKJoAAgHijg
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "ietf-pkix" <[e-mail]>
X-OriginalArrivalTime: 04 Aug 2009 12:31:04.0953 (UTC) FILETIME=[6F459E90:01CA14FF]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, image processing and extension reordering and the like *are*
baroque solutions to a simple problem.  We geeks like to brainstorm
about that sort of stuff.  But then we have to get real.

> Stefan Santesson wrote:
> However, I can't escape that it feels a bit warped if we abandon
useful
> features because we must design protocols to resist weak hashes
instead of
> making sure that we can and do use adequate hash algorithms.

I concur entirely.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Monday, August 03, 2009 5:06 PM
To: Kemp, David P.; ietf-pkix
Subject: RE: Embedded certificate image


Dave,

What you propose and Tom proposed seem to work from security viewpoint.
I do not know the impact on processing.  I assume some noise in graphics
should not impact it.=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73L6EUM011115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 14:06:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n73L6Eg9011114; Mon, 3 Aug 2009 14:06:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73L6CNE011107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 3 Aug 2009 14:06:13 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] (EHLO p03c11o141.symantecmail.net) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 541577a4.2053884848.85587.00-503.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Mon, 03 Aug 2009 15:06:13 -0600 (MDT)
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 241577a4.2768300976.85444.00-013.p03c11o141.symantecmail.net (envelope-from <[e-mail]>); Mon, 03 Aug 2009 15:06:10 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Embedded certificate image
Date: Mon, 3 Aug 2009 17:05:59 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Embedded certificate image
thread-index: AcoUOQZju1e67kdTSKWwyKSH/3Yj0AADvp3wAAxRyOAAATKJoA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Kemp, David P." <[e-mail]>, "ietf-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

What you propose and Tom proposed seem to work from security viewpoint.
I do not know the impact on processing.  I assume some noise in graphics
should not impact it.=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Kemp, David P.
> Sent: Monday, August 03, 2009 4:47 PM
> To: ietf-pkix
> Subject: RE: Embedded certificate image
>=20
>=20
> If a CA were going to accept user input to an image composed=20
> by the CA, then the composition process can provide=20
> confounding data by doing more than just "inserting a=20
> customer-provided graphic into a [known] template provided by=20
> the CA".  The Security Considerations section could recommend=20
> steganographic techniques for unpredictably modifying the=20
> image in perceptually-insignificant ways, such as by adding=20
> noise to the image data and/or inserting random tags in image=20
> formats for which tags are defined.
>=20
>=20
> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: Monday, August 03, 2009 10:39 AM
> To: Timothy J. Miller; Tom Gindin
> Cc: Stefan Santesson; ietf-pkix
> Subject: RE: Embedded certificate image
>=20
>=20
> Tim,
>=20
> Depending on the nature of collision, randomly reordering=20
> extensions may not help at all or may not provide=20
> sufficiently low probability of successful collision.
>=20
> > -----Original Message-----
> > From: Timothy J. Miller [mailto:[e-mail]]
> > Sent: Monday, August 03, 2009 8:51 AM
> > To: Tom Gindin
> > Cc: Stefan Santesson; ietf-pkix; Santosh Chokhani
> > Subject: Re: Embedded certificate image
> >=20
> > Tom Gindin wrote:
> > >         Stefan:
> > >=20
> > >         While it is unreasonable to dictate what a CA can=20
> accept, I=20
> > > think that the Security Considerations section should say=20
> something
> > > like: "the information about the certificate subject
> > contained in the
> > > image SHOULD NOT include any graphic supplied by the
> > applicant".  The
> > > "tumor" construct which we saw in MD5 collisions could be
> > placed into
> > > such a graphic.  Thus if a CA were to construct a graphic
> > by inserting
> > > a customer-provided graphic into a template provided by=20
> the CA, it=20
> > > would be subject to the same attacks as MD5 certificates=20
> have been,=20
> > > but it would not be evident from the certificate syntax.
> >=20
> > I'd rather require the CA to include a confounder in the=20
> prefix than=20
> > restrict the CAs ability to accept input.  There are=20
> multiple places=20
> > where a CA can do this; serial number being one (but more or less=20
> > difficult for some PKIs to implement), random-skew validity periods=20
> > being another.  To confound a prefix using this extension, random=20
> > reordering extensions is enough.
> >=20
> > -- Tim
> >=20
>=20
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73KkteQ009514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 13:46:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n73KktJj009513; Mon, 3 Aug 2009 13:46:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73KknqO009505 for <[e-mail]>; Mon, 3 Aug 2009 13:46:54 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Embedded certificate image
Date: Mon, 3 Aug 2009 16:46:41 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Embedded certificate image
Thread-Index: AcoUOQZju1e67kdTSKWwyKSH/3Yj0AADvp3wAAxRyOA=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "ietf-pkix" <[e-mail]>
X-OriginalArrivalTime: 03 Aug 2009 20:39:05.0328 (UTC) FILETIME=[71528700:01CA147A]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If a CA were going to accept user input to an image composed by the CA,
then the composition process can provide confounding data by doing more
than just "inserting a customer-provided graphic into a [known] template
provided by the CA".  The Security Considerations section could
recommend steganographic techniques for unpredictably modifying the
image in perceptually-insignificant ways, such as by adding noise to the
image data and/or inserting random tags in image formats for which tags
are defined.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Monday, August 03, 2009 10:39 AM
To: Timothy J. Miller; Tom Gindin
Cc: Stefan Santesson; ietf-pkix
Subject: RE: Embedded certificate image


Tim,

Depending on the nature of collision, randomly reordering extensions may
not help at all or may not provide sufficiently low probability of
successful collision.

> -----Original Message-----
> From: Timothy J. Miller [mailto:[e-mail]]=20
> Sent: Monday, August 03, 2009 8:51 AM
> To: Tom Gindin
> Cc: Stefan Santesson; ietf-pkix; Santosh Chokhani
> Subject: Re: Embedded certificate image
>=20
> Tom Gindin wrote:
> >         Stefan:
> >=20
> >         While it is unreasonable to dictate what a CA can accept, I=20
> > think that the Security Considerations section should say something=20
> > like: "the information about the certificate subject=20
> contained in the=20
> > image SHOULD NOT include any graphic supplied by the=20
> applicant".  The=20
> > "tumor" construct which we saw in MD5 collisions could be=20
> placed into=20
> > such a graphic.  Thus if a CA were to construct a graphic=20
> by inserting=20
> > a customer-provided graphic into a template provided by the CA, it=20
> > would be subject to the same attacks as MD5 certificates have been,=20
> > but it would not be evident from the certificate syntax.
>=20
> I'd rather require the CA to include a confounder in the=20
> prefix than restrict the CAs ability to accept input.  There=20
> are multiple places where a CA can do this; serial number=20
> being one (but more or less difficult for some PKIs to=20
> implement), random-skew validity periods being another.  To=20
> confound a prefix using this extension, random reordering=20
> extensions is enough.
>=20
> -- Tim
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73J3bQ4003544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 12:03:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n73J3bej003543; Mon, 3 Aug 2009 12:03:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73J3Xio003532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 3 Aug 2009 12:03:36 -0700 (MST) (envelope-from [e-mail])
Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id D168B325DE; Mon,  3 Aug 2009 20:03:31 +0100 (IST)
Received: from [10.87.48.10] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n73J3R2C031361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Aug 2009 20:03:28 +0100
Message-ID: <[e-mail]>
Date: Mon, 03 Aug 2009 20:03:34 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: "Turner, Sean P." <[e-mail]>
CC: pkix <[e-mail]>, IETF-Discussion <[e-mail]>
Subject: draft-turner-deviceowner-attribute last call comment
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 47066353 - be48e27a1725 (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Sean,

It seems odd to me that the only options for naming a device
owner are to use a country code or an OID that might represent
a group of countries (or something else).

Either this draft is only referring to some very special
devices or else its missing *much* more natural identifiers
for device owners, e.g. DNS names, email addresses etc.

So I think either change the ASN.1 (perhaps to include
a GeneralName in the choice) or else change the text to
say which kind(s) of device tend to be owned by countries
or groups of countries so that readers of the resulting RFC
have some kind of clue as to what the document is really
about.

I guess I'd prefer the former option, but since this is
going to be informational am fine with the latter so long
as its clear about the kind(s) of device to which the
putative RFC is meant to apply.

Cheers,
Stephen.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73EdnwV086564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 07:39:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n73EdnhN086563; Mon, 3 Aug 2009 07:39:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73Edf7u086543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 3 Aug 2009 07:39:47 -0700 (MST) (envelope-from [e-mail])
Received: from unknown [65.242.48.5] by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with SMTP id 4b6f67a4.3245202352.15228.00-017.p03c11o143.symantecmail.net (envelope-from <[e-mail]>); Mon, 03 Aug 2009 08:39:48 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Embedded certificate image
Date: Mon, 3 Aug 2009 10:39:29 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Embedded certificate image
thread-index: AcoUOQZju1e67kdTSKWwyKSH/3Yj0AADvp3w
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "ietf-pkix" <[e-mail]>
X-Spam: [F=0.2000000000; S=0.200(2009071501)]
X-MAIL-FROM: <[e-mail]>
X-SOURCE-IP: [65.242.48.5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

Depending on the nature of collision, randomly reordering extensions may
not help at all or may not provide sufficiently low probability of
successful collision.

> -----Original Message-----
> From: Timothy J. Miller [mailto:[e-mail]]=20
> Sent: Monday, August 03, 2009 8:51 AM
> To: Tom Gindin
> Cc: Stefan Santesson; ietf-pkix; Santosh Chokhani
> Subject: Re: Embedded certificate image
>=20
> Tom Gindin wrote:
> >         Stefan:
> >=20
> >         While it is unreasonable to dictate what a CA can accept, I=20
> > think that the Security Considerations section should say something=20
> > like: "the information about the certificate subject=20
> contained in the=20
> > image SHOULD NOT include any graphic supplied by the=20
> applicant".  The=20
> > "tumor" construct which we saw in MD5 collisions could be=20
> placed into=20
> > such a graphic.  Thus if a CA were to construct a graphic=20
> by inserting=20
> > a customer-provided graphic into a template provided by the CA, it=20
> > would be subject to the same attacks as MD5 certificates have been,=20
> > but it would not be evident from the certificate syntax.
>=20
> I'd rather require the CA to include a confounder in the=20
> prefix than restrict the CAs ability to accept input.  There=20
> are multiple places where a CA can do this; serial number=20
> being one (but more or less difficult for some PKIs to=20
> implement), random-skew validity periods being another.  To=20
> confound a prefix using this extension, random reordering=20
> extensions is enough.
>=20
> -- Tim
>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73Cp06j078863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 05:51:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n73CoxLG078862; Mon, 3 Aug 2009 05:50:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n73Col6l078847 for <[e-mail]>; Mon, 3 Aug 2009 05:50:58 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n73CogYa002992 for <[e-mail]>; Mon, 3 Aug 2009 08:50:47 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n73Cogvl002989; Mon, 3 Aug 2009 08:50:42 -0400
Received: from [172.31.15.249] (172.31.15.249) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 3 Aug 2009 08:50:42 -0400
Message-ID: <[e-mail]>
Date: Mon, 3 Aug 2009 07:50:38 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Stefan Santesson <[e-mail]>, ietf-pkix <[e-mail]>, Santosh Chokhani <[e-mail]>
Subject: Re: Embedded certificate image
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050008070600060901040508"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms050008070600060901040508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Gindin wrote:
>         Stefan:
> 
>         While it is unreasonable to dictate what a CA can accept, I think 
> that the Security Considerations section should say something like: "the 
> information about the certificate subject contained in the image SHOULD 
> NOT include any graphic supplied by the applicant".  The "tumor" construct 
> which we saw in MD5 collisions could be placed into such a graphic.  Thus 
> if a CA were to construct a graphic by inserting a customer-provided 
> graphic into a template provided by the CA, it would be subject to the 
> same attacks as MD5 certificates have been, but it would not be evident 
> from the certificate syntax.

I'd rather require the CA to include a confounder in the prefix than 
restrict the CAs ability to accept input.  There are multiple places 
where a CA can do this; serial number being one (but more or less 
difficult for some PKIs to implement), random-skew validity periods 
being another.  To confound a prefix using this extension, random 
reordering extensions is enough.

-- Tim

--------------ms050008070600060901040508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTA4MDMxMjUwMzhaMCMGCSqGSIb3DQEJBDEWBBTF7BlhlzE7EnRWG5AYyCvkMfuJDTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgE3Wrb7pgIlhDmO1nyGAa2C6ALfBSsH6ZY61M2x5Uc+pafDjIFZJnvsCT1Ct
kIGiv9g8dxRx0uIBwGJuRuI4zyzdIQ2VDMSOkz/BG9TxFWcLcTXsfdDzAAZjc6hTxfEydh7i
IQ/Jqsp1t2anhfBtAMhJc+rzml0PVBqYxFHiHGSbAAAAAAAA
--------------ms050008070600060901040508--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n719BXHl040815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2009 02:11:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n719BXbi040814; Sat, 1 Aug 2009 02:11:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [192.168.5.186] (50A1B9CF.flatrate.dk [80.161.185.207]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n719BTLi040806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 1 Aug 2009 02:11:32 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624080dc699b6dbba8b@[192.168.5.186]>
Date: Sat, 1 Aug 2009 11:11:26 +0200
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Two IETF Last Calls of interest to this WG
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Clearance Sponsor Attribute '
>   <draft-turner-clearancesponsor-attribute-01.txt> as an Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[e-mail] mailing lists by 2009-08-28. Exceptionally,
>comments may be sent to [e-mail] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-turner-clearancesponsor-attribute-01.txt
>



>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Device Owner Attribute '
>   <draft-turner-deviceowner-attribute-01.txt> as an Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[e-mail] mailing lists by 2009-08-28. Exceptionally,
>comments may be sent to [e-mail] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-turner-deviceowner-attribute-01.txt