Subject: I-D Action:draft-ietf-pkix-new-asn1-07.txt

From: [email-masked]
Date: Thu, 13 Aug 2009 18:15:01 -0700 (PDT)

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.

---

From: Sean Turner <[email-masked]>
Date: Mon, 31 Aug 2009 15:10:32 -0400

During the updates to RFC 3281 it was noted that the wrong OID was used 
for id-at-clearance.  We fixed this in draft-ietf-pkix-3281bis.  I would 
like to make sure we incorporate the same fix in 
draft-ietf-pkix-new-asn1.  If we don't, then we'll need to do another ID 
that incorporates this one change in an '02 ASN.1 module.  What I'm 
proposing is that make the following change:

OLD:

  id-at-clearance              OBJECT IDENTIFIER ::=
               { joint-iso-ccitt(2) ds(5) module(1)
                 selected-attribute-types(5) clearance (55) }

NEW:

   id-at-clearance              OBJECT IDENTIFIER ::= {
       joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }

     -- Uncomment the following declaration and comment the above line if
     -- using the id-at-clearance attribute as defined in [RFC3281]

     --  id-at-clearance              OBJECT IDENTIFIER ::= {
     --    joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
     --    clearance (55) }

spt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Aug 2009 12:39:27 -0700

At 3:10 PM -0400 8/31/09, Sean Turner wrote:
>During the updates to RFC 3281 it was noted that the wrong OID was used for id-at-clearance.  We fixed this in draft-ietf-pkix-3281bis.  I would like to make sure we incorporate the same fix in draft-ietf-pkix-new-asn1.  If we don't, then we'll need to do another ID that incorporates this one change in an '02 ASN.1 module.  What I'm proposing is that make the following change:
>
>OLD:
>

draft-ietf-pkix-new-asn1 has a module for RFC 3281. Jim and I believe that the module in our draft matches RFC 3281 correctly.

We can add another module that reflects draft-ietf-pkix-3281update-05.txt  (there is no draft-ietf-pkix-3281bis). However, we do not have any Internet Drafts in draft-ietf-pkix-new-asn1, and I personally think that it is unwise for us to add one at this late state. We could also wait for draft-ietf-pkix-3281update-05.txt to be published as an RFC and add a module for it to draft-ietf-pkix-new-asn1.

Personally, I think it is wrong to change the module for RFC 3281 to change bits on the wire from what is represented in RFC 3281.

---

From: Sean Turner <[email-masked]>
Date: Mon, 31 Aug 2009 18:08:55 -0400

> draft-ietf-pkix-new-asn1 has a module for RFC 3281. Jim and I believe that the module in our draft matches RFC 3281 correctly.

Not debating this.

> We can add another module that reflects draft-ietf-pkix-3281update-05.txt  (there is no draft-ietf-pkix-3281bis). However, we do not have any Internet Drafts in draft-ietf-pkix-new-asn1, and I pers…

I don't think it's too late in the process.  I'd rather fix this error 
now than have to publish another RFC later.

> Personally, I think it is wrong to change the module for RFC 3281 to change bits on the wire from what is represented in RFC 3281.

We did an update ID and it's passed PKIX WG LC and IETF LC and is now 
sitting in the RFC editor's queue pinned in a cluster with 7 other 
documents waiting on draft-ietf-pkix-sha2-dsa-ecdsa.  Other than this 
procedural issue, we'd probably not be having this conversation because 
it would be an RFC.  But since draft-ietf-pkix-3281update is already in 
the RFC editor's queue, I think it's pretty clear that the community 
wants this change incorporated in to any update of RFC 3281 and in my 
mind that includes draft-ietf-pkix-new-asn1.  I think it would be bad to 
have an updated RFC 3281 module that incorporates changes and an RFC 
with a later number that includes an ASN.1 module that essentially 
undoes the fixes.  Can't we just assume draft-ietf-pkix-3281update 
should pop out of the RFC editor's queue first (if only by hours/days) 
and just make this change now?  If not, then I'd advocate waiting for 
draft-ietf-pkix-3281update to be published as an RFC and adding the 
updated RFC 3281 module to draft-ietf-pkix-new-asn1.

In the original message, I forgot to add that we also need to include 
the following:

  -- Uncomment the following lines to support deprecated clearance
  -- syntax and comment out previous Clearance.

  -- Clearance ::= SEQUENCE {
  --  policyId            [0] OBJECT IDENTIFIER,
  --  classList           [1] ClassList DEFAULT {unclassified},
  --  securityCategories  [2] SET OF SecurityCategory  OPTIONAL
  -- }

spt

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 31 Aug 2009 21:34:33 +0200

Sean,

I'm OK with the change.

I also noted that there are a large amount of misspelled words in the draft,
mainly in the ASN.1 sections.

/Stefan

On 09-08-31 9:10 PM, "Sean Turner" <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Aug 2009 19:51:37 -0400

I have no objections to making these changes.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Aug 2009 17:19:42 -0700

>>draft-ietf-pkix-new-asn1 has a module for RFC 3281. Jim and I believe that the module in our draft matches RFC 3281 correctly.

Good. But...

>I don't think it's too late in the process. 

Agree.

>I'd rather fix this error now than have to publish another RFC later.

Above, you said you were not debating that our module in the draft matches RFC 3281 correctly. Where's the error? Or, did you mean "omission", meaning we do not yet have a module for draft-ietf-pkix-3281update?

>We did an update ID and it's passed PKIX WG LC and IETF LC and is now sitting in the RFC editor's queue pinned in a cluster with 7 other documents waiting on draft-ietf-pkix-sha2-dsa-ecdsa.  Other than this procedural issue, we'd probably not be having this conversation because it would be an RFC. 

If the WG asks us to add a new module for this draft, we're happy to do it.

>But since draft-ietf-pkix-3281update is already in the RFC editor's queue, I think it's pretty clear that the community wants this change incorporated in to any update of RFC 3281 and in my mind that includes draft-ietf-pkix-new-asn1.  I think it would be bad to have an updated RFC 3281 module that incorporates changes and an RFC with a later number that includes an ASN.1 module that essentially undoes the fixes.  Can't we just assume draft-ietf-pkix-3281update should pop out of the RFC editor's queue first (if only by hours/days) and just make this change now? 

Sure. But early on, there was an agreement that we were adding modules for RFCs, not Internet Drafts. This is the first we have heard of a request for this Internet Draft.

>If not, then I'd advocate waiting for draft-ietf-pkix-3281update to be published as an RFC and adding the updated RFC 3281 module to draft-ietf-pkix-new-asn1.

We could do that as well.

>
>In the original message, I forgot to add that we also need to include the following:
>

The WG has to decide whether to document RFC 3281, your non-compatible change, or both. You're assuming on the second choice, but I would rather hear from more people before we change our draft. Our draft is still technically in WG Last Call; the chairs haven't closed it after a month.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Aug 2009 17:38:14 -0700

>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?

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 01 Sep 2009 01:45:08 +0200

On a second thought I think I agree with Paul.

The OID error is unfortunate, but the ASN.1 document is not the place to
correct it.

/Stefan

On 09-08-31 9:39 PM, "Paul Hoffman" <[email-masked]> wrote:

>> During the updates to RFC 3281 it was noted that the wrong OID was used for
>> id-at-clearance.  We fixed this in draft-ietf-pkix-3281bis.  I would like to
>> make sure we incorporate the same fix in draft-ietf-pkix-new-asn1.  If we
>> don't, then we'll need to do another ID that incorporates this one change in
>> an '02 ASN.1 module.  What I'm proposing is that make the following change:
>> 
>> OLD:
>> 
> draft-ietf-pkix-new-asn1 has a module for RFC 3281. Jim and I believe that the
> module in our draft matches RFC 3281 correctly.
> 
> We can add another module that reflects draft-ietf-pkix-3281update-05.txt
> (there is no draft-ietf-pkix-3281bis). However, we do not have any Internet
> Drafts in draft-ietf-pkix-new-asn1, and I personally think that it is unwise
> for us to add one at this late state. We could also wait for
> draft-ietf-pkix-3281update-05.txt to be published as an RFC and add a module
> for it to draft-ietf-pkix-new-asn1.
> 
> Personally, I think it is wrong to change the module for RFC 3281 to change
> bits on the wire from what is represented in RFC 3281.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 01 Sep 2009 02:51:49 +0200

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" <[email-masked]> wrote:

> 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?
> 
> 

Date: Wed, 19 Aug 2009 12:15:19 -0400
To: Sean Turner <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Cc: Santosh Chokhani <[email-masked]>, Stefan Santesson <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Wed, 19 Aug 2009 11:10:07 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Sean Turner" <[email-masked]>, "Manger, James H" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]=20
> Sent: Wednesday, August 19, 2009 8:59 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> 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

Date: Wed, 19 Aug 2009 08:59:08 -0400
From: Sean Turner <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Sender: [email-masked]

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

Date: Wed, 19 Aug 2009 08:47:57 -0400
From: Sean Turner <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Sender: [email-masked]

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
> [email-masked]
> Identity and security team — Chief Technology Office — Telstra

Date: Wed, 19 Aug 2009 08:47:18 -0400
From: Sean Turner <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: Stefan Santesson <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Sender: [email-masked]

Santosh Chokhani wrote:
> Sean,
> 
> See responses below. 
> 
>> -----Original Message-----
>> From: Sean Turner [mailto:[email-masked]] 
>> Sent: Tuesday, August 18, 2009 8:27 AM
>> To: Stefan Santesson
>> Cc: Santosh Chokhani; [email-masked]
>> 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" 
>> <[email-masked]> 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:[email-masked]]
>>>>> Sent: Monday, August 17, 2009 4:47 PM
>>>>> To: Santosh Chokhani
>>>>> Cc: [email-masked]
>>>>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>>>>>
>>>>> Santosch,
>>>>>
>>>>>
>>>>> On 09-08-17 10:39 PM, "Santosh Chokhani"
>>>>> <[email-masked]> 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
>>>>>
>>>>>
>>>>>
>>>
>>>
> 

From: "Manger, James H" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 19 Aug 2009 14:47:35 +1000
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Accept-Language: en-US, en-AU
acceptlanguage: en-US, en-AU
Sender: [email-masked]

------=_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"

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

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Tue, 18 Aug 2009 22:46:17 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Manger, James H" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Jim,

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

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Manger, James H
> Sent: Tuesday, August 18, 2009 10:28 PM
> To: [email-masked]
> 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
> [email-masked]
> Identity and security team - Chief Technology Office - Telstra
>=20

From: "Manger, James H" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 19 Aug 2009 12:28:13 +1000
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Accept-Language: en-US, en-AU
acceptlanguage: en-US, en-AU
Sender: [email-masked]

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Tue, 18 Aug 2009 09:48:50 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Sean Turner" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Sean,

See responses below.=20

> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]=20
> Sent: Tuesday, August 18, 2009 8:27 AM
> To: Stefan Santesson
> Cc: Santosh Chokhani; [email-masked]
> 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
> <[email-masked]> 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:[email-masked]]
> >>> Sent: Monday, August 17, 2009 4:47 PM
> >>> To: Santosh Chokhani
> >>> Cc: [email-masked]
> >>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>>
> >>> Santosch,
> >>>
> >>>
> >>> On 09-08-17 10:39 PM, "Santosh Chokhani"
> >>> <[email-masked]> 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

Date: Tue, 18 Aug 2009 08:27:18 -0400
From: Sean Turner <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Santosh Chokhani <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Sender: [email-masked]

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" <[email-masked]> 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:[email-masked]]
>>> Sent: Monday, August 17, 2009 4:47 PM
>>> To: Santosh Chokhani
>>> Cc: [email-masked]
>>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>>>
>>> Santosch,
>>>
>>>
>>> On 09-08-17 10:39 PM, "Santosh Chokhani"
>>> <[email-masked]> 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
>>>
>>>
>>>
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Mon, 17 Aug 2009 17:22:58 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]=20
> Sent: Monday, August 17, 2009 5:16 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> 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
> <[email-masked]> 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:[email-masked]]
> >> Sent: Monday, August 17, 2009 4:47 PM
> >> To: Santosh Chokhani
> >> Cc: [email-masked]
> >> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
> >>=20
> >> Santosch,
> >>=20
> >>=20
> >> On 09-08-17 10:39 PM, "Santosh Chokhani"
> >> <[email-masked]> 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

Date: Mon, 17 Aug 2009 23:16:16 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

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" <[email-masked]> 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:[email-masked]]
>> Sent: Monday, August 17, 2009 4:47 PM
>> To: Santosh Chokhani
>> Cc: [email-masked]
>> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
>> 
>> Santosch,
>> 
>> 
>> On 09-08-17 10:39 PM, "Santosh Chokhani"
>> <[email-masked]> 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
>> 
>> 
>> 

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Mon, 17 Aug 2009 16:56:28 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]=20
> Sent: Monday, August 17, 2009 4:47 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> 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
> <[email-masked]> 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

Date: Mon, 17 Aug 2009 22:46:33 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

Santosch,

On 09-08-17 10:39 PM, "Santosh Chokhani" <[email-masked]> 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

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Mon, 17 Aug 2009 16:39:36 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]=20
> Sent: Monday, August 17, 2009 4:20 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> 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
> <[email-masked]> wrote:
>=20
> > Stefan,
> >=20
> > See responses in-line.
> >=20
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[email-masked]]
> >> Sent: Monday, August 17, 2009 3:58 AM
> >> To: Santosh Chokhani
> >> Cc: [email-masked]
> >> 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"
> >> <[email-masked]> 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

Date: Mon, 17 Aug 2009 22:19:33 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

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" <[email-masked]> wrote:

> Stefan,
> 
> See responses in-line.
> 
>> -----Original Message-----
>> From: Stefan Santesson [mailto:[email-masked]]
>> Sent: Monday, August 17, 2009 3:58 AM
>> To: Santosh Chokhani
>> Cc: [email-masked]
>> 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"
>> <[email-masked]> 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
>>> 
>> 
>> 
>> 

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Mon, 17 Aug 2009 15:55:16 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Stefan,

See responses in-line.=20

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]=20
> Sent: Monday, August 17, 2009 3:58 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> 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
> <[email-masked]> 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
>=20
>=20
> >=20
> > Santosh Chokhani
> > CygnaCom Solutions
> >=20
>=20
>=20
>=20

Date: Mon, 17 Aug 2009 09:57:32 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

Santosch,

Thanks for the clarifications. Comments in line.

On 09-08-13 12:37 AM, "Santosh Chokhani" <[email-masked]> 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

Date: Mon, 17 Aug 2009 08:53:29 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt
From: Stefan Santesson <[email-masked]>
To: Seth Hitchings <[email-masked]>, Santosh Chokhani <[email-masked]>, ietf-pkix <[email-masked]>
Sender: [email-masked]

Thanks Seth. Good catches both of them.

Comments in line.

On 09-08-14 4:47 PM, "Seth Hitchings" <[email-masked]> 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.

Date: Mon, 17 Aug 2009 08:10:27 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
From: Stefan Santesson <[email-masked]>
To: Sean Turner <[email-masked]>, <[email-masked]>
Sender: [email-masked]

In line;

On 09-08-16 3:58 PM, "Sean Turner" <[email-masked]> 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

Date: Sun, 16 Aug 2009 09:58:00 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: PKI support in W3C's HTML5
Date: Sun, 16 Aug 2009 10:13:57 +0200
Sender: [email-masked]

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

Date: Sat, 15 Aug 2009 15:34:54 -0400
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
Cc: [email-masked]
Sender: [email-masked]

>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

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Date: Fri, 14 Aug 2009 10:47:05 -0400
From: "Seth Hitchings" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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" <[email-masked]> 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

Date: Fri, 14 Aug 2009 16:06:33 +0200
Subject: Certificate image - remaining issues
From: Stefan Santesson <[email-masked]>
To: ietf-pkix <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 14 Aug 2009 15:43:24 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Stephen Kent <[email-masked]>, "Kemp, David P." <[email-masked]>
CC: ietf-pkix <[email-masked]>
Sender: [email-masked]

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" <[email-masked]> 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
> 

Date: Thu, 13 Aug 2009 18:18:39 -0700
To: Sean Turner <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-new-asn1-06.txt
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-new-asn1-07.txt 
Date: Thu, 13 Aug 2009 18:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

--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:     <[email-masked]>

--NextPart--

Date: Thu, 13 Aug 2009 16:52:45 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-new-asn1-06.txt
Sender: [email-masked]

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

[email-masked] wrote:
> 	Filename        : draft-ietf-pkix-new-asn1-06.txt
> 	Pages           : 120
> 	Date            : 2009-08-13
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-06.txt
> 

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-new-asn1-06.txt 
Date: Thu, 13 Aug 2009 06:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

	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

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

--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:     <[email-masked]>

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt
Date: Wed, 12 Aug 2009 18:37:05 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Date: Wed, 12 Aug 2009 10:37:57 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Skedd, Richard (UK)" <[email-masked]>
Cc: "Rob Sherwood" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]]=20
> Sent: Wednesday, August 12, 2009 7:25 AM
> To: Santosh Chokhani
> Cc: Rob Sherwood; [email-masked]
> 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:    +44 117 918 8034 (vnet 7658 8034)
> M:    +44 780 171 8260 (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: [email-masked]=20
> [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: 11 August 2009 22:06
> To: Rob Sherwood; [email-masked]
> 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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Rob Sherwood
> > Sent: Tuesday, August 11, 2009 12:35 PM
> > To: [email-masked]
> > 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

Date: Wed, 12 Aug 2009 10:36:50 -0400
From: Sean Turner <[email-masked]>
To: "Skedd, Richard (UK)" <[email-masked]>
CC: Santosh Chokhani <[email-masked]>, Rob Sherwood <[email-masked]>, [email-masked]
Subject: Re: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Sender: [email-masked]

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:    +44 117 918 8034 (vnet 7658 8034)
> M:    +44 780 171 8260 (vnet 777118260)
>  
> BAE Systems plc
> Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK
> Registered in England & Wales No: 1470151 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: 11 August 2009 22:06
> To: Rob Sherwood; [email-masked]
> 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: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Rob Sherwood
>> Sent: Tuesday, August 11, 2009 12:35 PM
>> To: [email-masked]
>> 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.
> ********************************************************************
> 
> 

Date: Wed, 12 Aug 2009 10:18:47 -0400
To: "Manger, James H" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt 
Cc: [email-masked]
Sender: [email-masked]

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
>[email-masked]
>Identity and security team � Chief Technology Office � Telselstra
>
>----------
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of [email-masked]
>Sent: Wednesday, 12 August 2009 7:00 AM
>Subject: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt
>
>         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.
>
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-attr-cert-mime-type-00.txt
>

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Date: Wed, 12 Aug 2009 10:11:59 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]=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
> <[email-masked]> 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ocspagility-02.txt 
Date: Wed, 12 Aug 2009 06:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

	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

--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:     <[email-masked]>

--NextPart--

Date: Wed, 12 Aug 2009 15:06:09 +0200
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt
From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>, ietf-pkix <[email-masked]>
Sender: [email-masked]

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" <[email-masked]> 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"
> 

Content-class: urn:content-classes:message
Subject: RE: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Date: Wed, 12 Aug 2009 12:25:16 +0100
From: "Skedd, Richard (UK)" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>
Cc: "Rob Sherwood" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:    +44 117 918 8034 (vnet 7658 8034)
M:    +44 780 171 8260 (vnet 777118260)
 
BAE Systems plc
Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK
Registered in England & Wales No: 1470151 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: 11 August 2009 22:06
To: Rob Sherwood; [email-masked]
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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Rob Sherwood
> Sent: Tuesday, August 11, 2009 12:35 PM
> To: [email-masked]
> 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.
********************************************************************

From: "Manger, James H" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 12 Aug 2009 13:47:40 +1000
Subject: RE: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt 
Accept-Language: en-US, en-AU
acceptlanguage: en-US, en-AU
Sender: [email-masked]

Date: Tue, 11 Aug 2009 17:41:14 -0700
To: Stephen Kent <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 11 Aug 2009 18:54:21 -0400
To: Sean Turner <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 11 Aug 2009 18:36:52 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
Sender: [email-masked]

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
> 
> [email-masked] wrote:
>>     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).
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
>>

Content-class: urn:content-classes:message
Subject: RE: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Date: Tue, 11 Aug 2009 17:06:02 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Rob Sherwood" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Rob,

See responses in-line below.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Rob Sherwood
> Sent: Tuesday, August 11, 2009 12:35 PM
> To: [email-masked]
> 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-attr-cert-mime-type-00.txt 
Date: Tue, 11 Aug 2009 14:00:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

	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

--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:     <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-08.txt 
Date: Tue, 11 Aug 2009 12:30:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

	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

--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:     <[email-masked]>

--NextPart--

Date: Tue, 11 Aug 2009 13:07:25 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
Sender: [email-masked]

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

[email-masked] wrote:
> 	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).
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-07.txt
> 

Content-class: urn:content-classes:message
Subject: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt
Date: Tue, 11 Aug 2009 12:35:25 -0400
From: "Rob Sherwood" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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)

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt
Date: Mon, 10 Aug 2009 12:04:17 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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"

Date: Sun, 9 Aug 2009 06:32:13 -0700
To: [email-masked], Sean Turner <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: SMIME report (IETF 75)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-07.txt 
Date: Tue,  4 Aug 2009 12:30:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

	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

--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:     <[email-masked]>

--NextPart--

Date: Tue, 4 Aug 2009 10:27:17 -0400
To: "Kemp, David P." <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Embedded certificate image
Cc: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 04 Aug 2009 14:36:46 +0100
From: Stephen Farrell <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: "Kemp, David P." <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

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: [email-masked] 
>> [mailto:[email-masked]] 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: [email-masked] 
>> [mailto:[email-masked]]
>> 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:[email-masked]]
>>> 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
>>>
>>
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Mon, 3 Aug 2009 16:46:41 -0400
From: "Kemp, David P." <[email-masked]>
To: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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:=[email-masked]=20[mailto:[email-masked]=
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:[email-masked]]=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=[email-masked].=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
[email-masked]

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

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

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Tue, 4 Aug 2009 08:37:22 -0400
From: "Kemp, David P." <[email-masked]>
To: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Mon, 3 Aug 2009 17:05:59 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Kemp, David P." <[email-masked]>, "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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: [email-masked]=20
> [mailto:[email-masked]] 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: [email-masked]=20
> [mailto:[email-masked]]
> 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:[email-masked]]
> > 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

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Mon, 3 Aug 2009 16:46:41 -0400
From: "Kemp, David P." <[email-masked]>
To: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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:[email-masked]]=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

Date: Mon, 03 Aug 2009 20:03:34 +0100
From: Stephen Farrell <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
CC: pkix <[email-masked]>, IETF-Discussion <[email-masked]>
Subject: draft-turner-deviceowner-attribute last call comment
Sender: [email-masked]

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.

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Mon, 3 Aug 2009 10:39:29 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Timothy J. Miller" <[email-masked]>, "Tom Gindin" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "ietf-pkix" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]=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

Date: Mon, 3 Aug 2009 07:50:38 -0500
From: "Timothy J. Miller" <[email-masked]>
To: Tom Gindin <[email-masked]>
CC: Stefan Santesson <[email-masked]>, ietf-pkix <[email-masked]>, Santosh Chokhani <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

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

--------------ms050008070600060901040508--

Date: Sat, 1 Aug 2009 11:11:26 +0200
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Two IETF Last Calls of interest to this WG
Sender: [email-masked]

>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
>[email-masked] mailing lists by 2009-08-28. Exceptionally,
>comments may be sent to [email-masked] 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
>[email-masked] mailing lists by 2009-08-28. Exceptionally,
>comments may be sent to [email-masked] 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