Subject: draft-ietf-pkix-scvp-25.txt

From: "yannick quenechdu" <[email-masked]>
Date: Wed, 31 May 2006 18:11:59 +0200 (CEST)

Hi,

I would wish a clarification by the way

Date: Wed, 31 May 2006 18:21:03 +0200 (CEST)
Subject: [Fwd: draft-ietf-pkix-scvp-25.txt]
From: "yannick quenechdu" <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Importance: Normal
Sender: [email-masked]

Hi,

I would wish a clarification about section 3 :

"If the extended key usage extension is present, it MUST contain either
the SCVP client OID (see Section 3.10) or another OID acceptable to the
SCVP server."

I do not see the relation with section 3.10. It is necessary to use the
field RequestorText to indicate a OID for SCVP client ?

Thanks;
---
Yannick quenec'hdu
Security architect
Linagora

Date: Wed, 31 May 2006 18:11:59 +0200 (CEST)
Subject: draft-ietf-pkix-scvp-25.txt
From: "yannick quenechdu" <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Importance: Normal
Sender: [email-masked]

Hi,

I would wish a clarification by the way

Date: Wed, 31 May 2006 14:10:38 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-pkix-scvp-24.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060600060808050403090900
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I am fine with this clarification.

Russ Housley wrote:
>
> Peter:
>
> I can see making this point in the text to add clarity, but the need 
> for anything else is just not coming through.
>
>> - When protectResponse is TRUE, the server MUST protect the response
>> independantly of the protection of the transport.
>
> Russ
>
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite'; 
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms060600060808050403090900--

Date: Tue, 30 May 2006 16:51:44 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Cc: [email-masked]
Sender: [email-masked]

Peter:

I can see making this point in the text to add clarity, but the need 
for anything else is just not coming through.

>- When protectResponse is TRUE, the server MUST protect the response
>independantly of the protection of the transport.

Russ 

Date: Tue, 30 May 2006 21:05:07 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-pkix-scvp-24.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020903050100020702060402
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Russ Housley wrote:
> This does not make sense to me.  Why do you want to require the 
> inclusion of an OPTIONAL field when the the semantic result is the same?
>
oops, I messed up  "protectResponse"   and  "responseFlags" in

   such clients MUST always
   set this value to TRUE or omit the responseFlags item entirely,
   which requires the server to return a protected response.

Following David's argument, even when not encoding the optional
responseflags,     protectResponse is then TRUE. 
Or, in this sentence, the first half talks about the value of an boolean,
and the second about how to encode something.

> Russ
>
> At 12:05 PM 5/30/2006, Peter Sylvester wrote:
>
>> I think I already did.
>>
>>    Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the 
>> sentence  removed.
>>
>> In fact, I suggested for all cases to avoid the potential 
>> misinterpretation, and my message
>> from months ago suggested textual changes.
>>
>> And in my previous:
>>
>> Point 1 in paragraph 4
>>
>>   1. A success response to a request made over a protected transport
>>      such as TLS.  These responses SHOULD NOT be protected by the
>>      server.
>>
>> If the client indicates a TRUE value in a protectResponse, then the 
>> previous seems not
>> good to me:
>>
>> - When a TLS is used then a client MAY choose not indicate a FALSE
>> value for protectResponses.
>> - When TLS is used and protectResponses is FALSE then a server
>> SHOULD NOT not to protect the response. (I am not sure whether
>> this would even be better MAY NOT).
>> - When protectResponse is TRUE, the server MUST protect the response
>> independantly of the protection of the transport.
>>
>>
>> Russ Housley wrote:
>>> I interpreted your previous not in a much different light.  Can you 
>>> suggest text that would resolve your concern?
>>>
>>> Russ
>>>
>>> At 10:51 AM 5/30/2006, Peter Sylvester wrote:
>>>> Russ Housley wrote:
>>>>> Peter:
>>>>>
>>>>> I believe that this was discussed.  I think we need to ship the 
>>>>> document.  Delay is causing problems.
>>>>
>>>>
>>>> When, where, there was no response to my message? You hay have 
>>>> discussed something at the
>>>> last IETF, but this is not in the minutes, and I never received an 
>>>> reply to my message.
>>>>
>>>> How can you claim that something has been discussed that I just 
>>>> mentioned fo the first time as
>>>> a response to david?
>>>>
>>>> ===>
>>>>
>>>> Anyway:
>>>>
>>>> SCVP clients that support delegated path validation (DPV) as defined
>>>>  in [RQMTS] require an authenticated response.  Unless a protected
>>>>  transport mechanism (such a TLS) is used, such clients MUST always
>>>>  set this value to TRUE or omit the responseFlags item entirely,
>>>>  which requires the server to return a protected response.
>>>>
>>>> Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the 
>>>> sentence
>>>> removed.
>>>>
>>>> You might consider to add the explanations above to the text, since 
>>>> there are
>>>> people out that do not have 20 years of experience with ASN.1 and 
>>>> its encodings.
>>>> This is not the first occurence of such wording, and people have 
>>>> created errors
>>>> in encodings. (e.g. with 3161).
>>>> You may try to understand my suggestion as an attempt to avoid 
>>>> misinterpretations of
>>>> using the verb 'set' concerning of the value of an item and how it 
>>>> is encoded.
>>>>
>>>>
>>>> -- 
>>>> To verify the signature, see http://edelpki.edelweb.fr/ Cela vous 
>>>> permet de charger le certificat de l'autorité; die Liste mit 
>>>> zurückgerufenen Zertifikaten finden Sie da auch.
>>>
>>>
>>
>>
>> -- 
>> To verify the signature, see http://edelpki.edelweb.fr/ Cela vous 
>> permet de charger le certificat de l'autorité; die Liste mit 
>> zurückgerufenen Zertifikaten finden Sie da auch.
>
>
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms020903050100020702060402--

Date: Tue, 30 May 2006 13:06:05 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Cc: [email-masked]
Sender: [email-masked]

This does not make sense to me.  Why do you want to require the 
inclusion of an OPTIONAL field when the the semantic result is the same?

Russ

At 12:05 PM 5/30/2006, Peter Sylvester wrote:

>I think I already did.
>
>    Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the 
> sentence  removed.
>
>In fact, I suggested for all cases to avoid the potential 
>misinterpretation, and my message
>from months ago suggested textual changes.
>
>And in my previous:
>
>Point 1 in paragraph 4
>
>   1. A success response to a request made over a protected transport
>      such as TLS.  These responses SHOULD NOT be protected by the
>      server.
>
>If the client indicates a TRUE value in a protectResponse, then the 
>previous seems not
>good to me:
>
>- When a TLS is used then a client MAY choose not indicate a FALSE
>value for protectResponses.
>- When TLS is used and protectResponses is FALSE then a server
>SHOULD NOT not to protect the response. (I am not sure whether
>this would even be better MAY NOT).
>- When protectResponse is TRUE, the server MUST protect the response
>independantly of the protection of the transport.
>
>
>Russ Housley wrote:
>>I interpreted your previous not in a much different light.  Can you 
>>suggest text that would resolve your concern?
>>
>>Russ
>>
>>At 10:51 AM 5/30/2006, Peter Sylvester wrote:
>>>Russ Housley wrote:
>>>>Peter:
>>>>
>>>>I believe that this was discussed.  I think we need to ship the 
>>>>document.  Delay is causing problems.
>>>
>>>
>>>When, where, there was no response to my message? You hay have 
>>>discussed something at the
>>>last IETF, but this is not in the minutes, and I never received an 
>>>reply to my message.
>>>
>>>How can you claim that something has been discussed that I just 
>>>mentioned fo the first time as
>>>a response to david?
>>>
>>>===>
>>>
>>>Anyway:
>>>
>>>SCVP clients that support delegated path validation (DPV) as defined
>>>  in [RQMTS] require an authenticated response.  Unless a protected
>>>  transport mechanism (such a TLS) is used, such clients MUST always
>>>  set this value to TRUE or omit the responseFlags item entirely,
>>>  which requires the server to return a protected response.
>>>
>>>Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the sentence
>>>removed.
>>>
>>>You might consider to add the explanations above to the text, 
>>>since there are
>>>people out that do not have 20 years of experience with ASN.1 and 
>>>its encodings.
>>>This is not the first occurence of such wording, and people have 
>>>created errors
>>>in encodings. (e.g. with 3161).
>>>You may try to understand my suggestion as an attempt to avoid 
>>>misinterpretations of
>>>using the verb 'set' concerning of the value of an item and how it 
>>>is encoded.
>>>
>>>
>>>--
>>>To verify the signature, see http://edelpki.edelweb.fr/ Cela vous 
>>>permet de charger le certificat de l'autorité; die Liste mit 
>>>zurückgerufenen Zertifikaten finden Sie da auch.
>>
>>
>
>
>--
>To verify the signature, see http://edelpki.edelweb.fr/ Cela vous 
>permet de charger le certificat de l'autorité; die Liste mit 
>zurückgerufenen Zertifikaten finden Sie da auch.

Date: Tue, 30 May 2006 18:05:30 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-pkix-scvp-24.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

I think I already did.

    Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the 
sentence  removed.

In fact, I suggested for all cases to avoid the potential 
misinterpretation, and my message
from months ago suggested textual changes.

And in my previous:

Point 1 in paragraph 4

   1. A success response to a request made over a protected transport
      such as TLS.  These responses SHOULD NOT be protected by the
      server.

If the client indicates a TRUE value in a protectResponse, then the 
previous seems not
good to me:

- When a TLS is used then a client MAY choose not indicate a FALSE
 value for protectResponses.
- When TLS is used and protectResponses is FALSE then a server
 SHOULD NOT not to protect the response. (I am not sure whether
 this would even be better MAY NOT).
- When protectResponse is TRUE, the server MUST protect the response
 independantly of the protection of the transport.

Russ Housley wrote:
> I interpreted your previous not in a much different light.  Can you 
> suggest text that would resolve your concern?
>
> Russ
>
> At 10:51 AM 5/30/2006, Peter Sylvester wrote:
>> Russ Housley wrote:
>>> Peter:
>>>
>>> I believe that this was discussed.  I think we need to ship the 
>>> document.  Delay is causing problems.
>>>
>>
>>
>> When, where, there was no response to my message? You hay have 
>> discussed something at the
>> last IETF, but this is not in the minutes, and I never received an 
>> reply to my message.
>>
>> How can you claim that something has been discussed that I just 
>> mentioned fo the first time as
>> a response to david?
>>
>> ===>
>>
>> Anyway:
>>
>> SCVP clients that support delegated path validation (DPV) as defined
>>  in [RQMTS] require an authenticated response.  Unless a protected
>>  transport mechanism (such a TLS) is used, such clients MUST always
>>  set this value to TRUE or omit the responseFlags item entirely,
>>  which requires the server to return a protected response.
>>
>> Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the 
>> sentence
>> removed.
>>
>> You might consider to add the explanations above to the text, since 
>> there are
>> people out that do not have 20 years of experience with ASN.1 and its 
>> encodings.
>> This is not the first occurence of such wording, and people have 
>> created errors
>> in encodings. (e.g. with 3161).
>> You may try to understand my suggestion as an attempt to avoid 
>> misinterpretations of
>> using the verb 'set' concerning of the value of an item and how it is 
>> encoded.
>>
>>
>> -- 
>> To verify the signature, see http://edelpki.edelweb.fr/ Cela vous 
>> permet de charger le certificat de l'autorité; die Liste mit 
>> zurückgerufenen Zertifikaten finden Sie da auch.
>
>
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms090906010607050503030301--

Date: Tue, 30 May 2006 11:45:16 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Cc: pkix <[email-masked]>
Sender: [email-masked]

I interpreted your previous not in a much different light.  Can you 
suggest text that would resolve your concern?

Russ

At 10:51 AM 5/30/2006, Peter Sylvester wrote:
>Russ Housley wrote:
>>Peter:
>>
>>I believe that this was discussed.  I think we need to ship the 
>>document.  Delay is causing problems.
>>
>
>
>When, where, there was no response to my message? You hay have 
>discussed something at the
>last IETF, but this is not in the minutes, and I never received an 
>reply to my message.
>
>How can you claim that something has been discussed that I just 
>mentioned fo the first time as
>a response to david?
>
>===>
>
>Anyway:
>
>SCVP clients that support delegated path validation (DPV) as defined
>  in [RQMTS] require an authenticated response.  Unless a protected
>  transport mechanism (such a TLS) is used, such clients MUST always
>  set this value to TRUE or omit the responseFlags item entirely,
>  which requires the server to return a protected response.
>
>Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the sentence
>removed.
>
>You might consider to add the explanations above to the text, since there are
>people out that do not have 20 years of experience with ASN.1 and 
>its encodings.
>This is not the first occurence of such wording, and people have 
>created errors
>in encodings. (e.g. with 3161).
>You may try to understand my suggestion as an attempt to avoid 
>misinterpretations of
>using the verb 'set' concerning of the value of an item and how it is encoded.
>
>
>--
>To verify the signature, see http://edelpki.edelweb.fr/ Cela vous 
>permet de charger le certificat de l'autorité; die Liste mit 
>zurückgerufenen Zertifikaten finden Sie da auch.

Date: Tue, 30 May 2006 16:51:35 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Russ Housley wrote:
> Peter:
>
> I believe that this was discussed.  I think we need to ship the 
> document.  Delay is causing problems.
>
>

When, where, there was no response to my message? You hay have discussed 
something at the
last IETF, but this is not in the minutes, and I never received an reply 
to my message.

How can you claim that something has been discussed that I just 
mentioned fo the first time as
a response to david?

===>

Anyway:

 SCVP clients that support delegated path validation (DPV) as defined
  in [RQMTS] require an authenticated response.  Unless a protected
  transport mechanism (such a TLS) is used, such clients MUST always
  set this value to TRUE or omit the responseFlags item entirely,
  which requires the server to return a protected response.

Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the sentence
removed.

You might consider to add the explanations above to the text, since 
there are
people out that do not have 20 years of experience with ASN.1 and its 
encodings.
This is not the first occurence of such wording, and people have created 
errors
in encodings. (e.g. with 3161).
You may try to understand my suggestion as an attempt to avoid 
misinterpretations of
using the verb 'set' concerning of the value of an item and how it is 
encoded.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms040100050001070200010809--

Date: Tue, 30 May 2006 10:14:51 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Cc: pkix <[email-masked]>
Sender: [email-masked]

Peter:

I believe that this was discussed.  I think we need to ship the 
document.  Delay is causing problems.

Russ

At 08:50 AM 5/28/2006, Peter Sylvester wrote:

>David A. Cooper wrote:
>>
>>Peter Sylvester wrote:
>>
>>>It seems that you have not addressed at all the inconsistencies
>>>mentioned in:
>>>
>>>      http://www.imc.org/ietf-pkix/mail-archive/msg03248.html
>>
>>Peter,
>>
>>I looked over this message again and see that we did forget to 
>>change "requestorName" to "responderName" in section 3.6.  We can 
>>correct this in authors' 48 hours.  I do not believe that any other 
>>changes need to be made to this document.
>Paul Hoffman reponded yo the first sentence.
>
>You are the editor, and you don't want to make more changes?
>
>>
>>Most of your comments seem to be related to your claim that 
>>statements of the form "value X MUST be set to TRUE" are incorrect 
>>if the ASN.1 specifies a DEFAULT value of TRUE for X.  This seems 
>>to be confusing "DEFAULT" and "OPTIONAL", which are encoded 
>>similarly in DER but have very different semantics.  When the 
>>ResponseFlags item appears in a request, each of its fields 
>>(fullRequestInResponse, responseValidationPolByRef, 
>>protectResponse, and cachedResponse) must be set to either TRUE or 
>>FALSE.  This is a requirement since none of the fields are 
>>OPTIONAL.  The fact that a DEFAULT value is defined for each of the 
>>fields does not change this.  The presence of DEFAULT values 
>>affects how ResponseFlags is encoded using DER, but does not affect 
>>the fact that each of these fields must be assigned a value of 
>>either TRUE or FALSE.  Note that the text never says "MUST be set 
>>to TRUE in the encoding", it always says "MUST be set to TRUE".
>Most of relate  comments relate to different things than this small 
>propblem of
>wording of how to encode a two value item.  It would be nice iff you could
>address them in a similar detailed way as this small detail:
>
>Anyway:
>
>  SCVP clients that support delegated path validation (DPV) as defined
>   in [RQMTS] require an authenticated response.  Unless a protected
>   transport mechanism (such a TLS) is used, such clients MUST always
>   set this value to TRUE or omit the responseFlags item entirely,
>   which requires the server to return a protected response.
>
>Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the sentence
>removed.
>
>You might consider to add the explanations above to the text, since there are
>people out that do not have 20 years of experience with ASN.1 and 
>its encodings.
>This is not the first occurence of such wording, and people have 
>created errors
>in encodings. (e.g. with 3161).
>You may try to understand my suggestion as an attempt to avoid 
>misinterpretations of
>using the verb 'set' concerning of the value of an item and how it is encoded.
>
>
>>
>>You also claim that there is something in section 3.10 that is 
>>inconsistent with RFC 3379.  However, Tim Polk used the RFC 3379 
>>compliance matrices to demonstrate that SCVP meets all the 
>>requirements of RFC 3379.  The text that appears in section 3.10 
>>was discussed at length in late January and early February and at 
>>that point there seemed to be agreement that the text addressed 
>>item #14 in the requirements matrix.
>Frankly, I don't care whether some religious or scientific person 
>had declared that the Sun is turning
>around Earth.
>
>paragraph 3.10
>
>This is inconsistent with the 3379. 3379 does not allow a server
>not to copy the field.
>
>
>3379
>
>The DPV server MUST be able, upon request, copy a text field provided
>   by the client into the DPV response.  As an example, this field may
>   relate to the nature or reason for the DPV query.
>
>SCVP draft
>
>   Conforming SCVP client implementations MAY support inclusion of this
>   item in requests.  Conforming SCVP Server implementations MUST
>   accept requests that include this item.  When generating non-cached
>   responses, conforming SCVP Server implementations MUST copy the
>   contents of this item into the requestorText item in the
>   corresponding response (see Section 4.13).
>
>The SCVP text seems reasonable but the client expects that text to 
>be returned,
>otherwise why bother to set it in the request. Or, one could deduce 
>that cached
>responses cannot be produced in that case. If the client does not 
>indicate that
>it doesn't want cached responses, it is not clear whether a conforming server
>can respond with a cached response without copying the response.
>
>
>Point 1 in paragraph 4
>
>    1. A success response to a request made over a protected transport
>       such as TLS.  These responses SHOULD NOT be protected by the
>       server.
>
>If the client indicates a TRUE value in a protectResponse, then the 
>previous seems not
>good to me:
>
>- When a TLS is used then a client MAY choose not indicate a FALSE
>  value for protectResponses.
>- When TLS is used and protectResponses is FALSE then a server
>  SHOULD NOT not to protect the response. (I am not sure whether
>  this would even be better MAY NOT).
>- When protectResponse is TRUE, the server MUST protect the response
>  independantly of the protection of the transport.
>
>
>>
>>Dave
>>
>>
>
>
>--
>To verify the signature, see http://edelpki.edelweb.fr/ Cela vous 
>permet de charger le certificat de l'autorité; die Liste mit 
>zurückgerufenen Zertifikaten finden Sie da auch.

Content-class: urn:content-classes:message
Subject: GOST: Bad DNs in RFC 4491 examples
Date: Tue, 30 May 2006 15:02:35 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I guess it is too late to put sensible distinguished names in the sample certificates [issuer and subject fields in certs from sections 4.1 and 4.2].

1. An email address should go in the subjectAltName.rfc822Name extension.  [Actually it MUST go there according to the last paragraph of section 4.1.2.6 "Subject" in RFC 3280]
2. The country, org and common name RDNs are in the wrong order.

Current DN (in pseudo RFC2253 format and pseudo value notation):

EMAILADDRESS=[email-masked],C=RU,O=CryptoPro,CN=GostR3410-94 example

 subject rdnSequence:{
   commonName utf8String:"GostR3410-94 example"
   / organizationName utf8String:"CryptoPro"
   / countryName "RU"
   / emailAddress "[email-masked]"
 },

Date: Sun, 28 May 2006 14:50:45 +0200
From: Peter Sylvester <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

David A. Cooper wrote:
>
> Peter Sylvester wrote:
>
>> It seems that you have not addressed at all the inconsistencies
>> mentioned in:
>>
>>      http://www.imc.org/ietf-pkix/mail-archive/msg03248.html
>
> Peter,
>
> I looked over this message again and see that we did forget to change 
> "requestorName" to "responderName" in section 3.6.  We can correct 
> this in authors' 48 hours.  I do not believe that any other changes 
> need to be made to this document.
Paul Hoffman reponded yo the first sentence.

You are the editor, and you don't want to make more changes?

>
> Most of your comments seem to be related to your claim that statements 
> of the form "value X MUST be set to TRUE" are incorrect if the ASN.1 
> specifies a DEFAULT value of TRUE for X.  This seems to be confusing 
> "DEFAULT" and "OPTIONAL", which are encoded similarly in DER but have 
> very different semantics.  When the ResponseFlags item appears in a 
> request, each of its fields (fullRequestInResponse, 
> responseValidationPolByRef, protectResponse, and cachedResponse) must 
> be set to either TRUE or FALSE.  This is a requirement since none of 
> the fields are OPTIONAL.  The fact that a DEFAULT value is defined for 
> each of the fields does not change this.  The presence of DEFAULT 
> values affects how ResponseFlags is encoded using DER, but does not 
> affect the fact that each of these fields must be assigned a value of 
> either TRUE or FALSE.  Note that the text never says "MUST be set to 
> TRUE in the encoding", it always says "MUST be set to TRUE".
Most of relate  comments relate to different things than this small 
propblem of
wording of how to encode a two value item.  It would be nice iff you could
address them in a similar detailed way as this small detail:

Anyway:

  SCVP clients that support delegated path validation (DPV) as defined
   in [RQMTS] require an authenticated response.  Unless a protected
   transport mechanism (such a TLS) is used, such clients MUST always
   set this value to TRUE or omit the responseFlags item entirely,
   which requires the server to return a protected response.

Shouldn't the  the 'or' be changed into 'i.e.' or he rest of the sentence
removed.

You might consider to add the explanations above to the text, since 
there are
people out that do not have 20 years of experience with ASN.1 and its 
encodings.
This is not the first occurence of such wording, and people have created 
errors
in encodings. (e.g. with 3161).
You may try to understand my suggestion as an attempt to avoid 
misinterpretations of
using the verb 'set' concerning of the value of an item and how it is 
encoded.

>
> You also claim that there is something in section 3.10 that is 
> inconsistent with RFC 3379.  However, Tim Polk used the RFC 3379 
> compliance matrices to demonstrate that SCVP meets all the 
> requirements of RFC 3379.  The text that appears in section 3.10 was 
> discussed at length in late January and early February and at that 
> point there seemed to be agreement that the text addressed item #14 in 
> the requirements matrix.
Frankly, I don't care whether some religious or scientific person had 
declared that the Sun is turning
around Earth.

paragraph 3.10

This is inconsistent with the 3379. 3379 does not allow a server
not to copy the field.

3379

 The DPV server MUST be able, upon request, copy a text field provided
   by the client into the DPV response.  As an example, this field may
   relate to the nature or reason for the DPV query.

SCVP draft

   Conforming SCVP client implementations MAY support inclusion of this
   item in requests.  Conforming SCVP Server implementations MUST
   accept requests that include this item.  When generating non-cached
   responses, conforming SCVP Server implementations MUST copy the
   contents of this item into the requestorText item in the
   corresponding response (see Section 4.13).

The SCVP text seems reasonable but the client expects that text to be 
returned,
otherwise why bother to set it in the request. Or, one could deduce that 
cached
responses cannot be produced in that case. If the client does not 
indicate that
it doesn't want cached responses, it is not clear whether a conforming 
server
can respond with a cached response without copying the response.

Point 1 in paragraph 4

    1. A success response to a request made over a protected transport
       such as TLS.  These responses SHOULD NOT be protected by the
       server.

If the client indicates a TRUE value in a protectResponse, then the 
previous seems not
good to me:

- When a TLS is used then a client MAY choose not indicate a FALSE
  value for protectResponses.
- When TLS is used and protectResponses is FALSE then a server
  SHOULD NOT not to protect the response. (I am not sure whether
  this would even be better MAY NOT).
- When protectResponse is TRUE, the server MUST protect the response
  independantly of the protection of the transport.

> Dave

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms070601020006050508080005--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-25.txt 
Date: Fri, 26 May 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Server-based Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-25.txt
	Pages		: 84
	Date		: 2006-5-26
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-25.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-25.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-25.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 25 May 2006 15:51:32 -0700
To: "David A. Cooper" <[email-masked]>, Peter Sylvester <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Cc: pkix <[email-masked]>
Sender: [email-masked]

At 4:02 PM -0400 5/25/06, David A. Cooper wrote:
>I looked over this message again and see that we did forget to 
>change "requestorName" to "responderName" in section 3.6.  We can 
>correct this in authors' 48 hours.

<process-alert>
BLARG! That is a significant technical change! That is *not* what 
AUTH48 is for.
</process-alert>

Please consider issuing a new draft with that change. That's what the 
I-D process is for.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 25 May 2006 16:02:15 -0400
From: "David A. Cooper" <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Sender: [email-masked]

Peter Sylvester wrote:

> It seems that you have not addressed at all the inconsistencies
> mentioned in:
>
>      http://www.imc.org/ietf-pkix/mail-archive/msg03248.html

Peter,

I looked over this message again and see that we did forget to change 
"requestorName" to "responderName" in section 3.6.  We can correct this 
in authors' 48 hours.  I do not believe that any other changes need to 
be made to this document.

Most of your comments seem to be related to your claim that statements 
of the form "value X MUST be set to TRUE" are incorrect if the ASN.1 
specifies a DEFAULT value of TRUE for X.  This seems to be confusing 
"DEFAULT" and "OPTIONAL", which are encoded similarly in DER but have 
very different semantics.  When the ResponseFlags item appears in a 
request, each of its fields (fullRequestInResponse, 
responseValidationPolByRef, protectResponse, and cachedResponse) must be 
set to either TRUE or FALSE.  This is a requirement since none of the 
fields are OPTIONAL.  The fact that a DEFAULT value is defined for each 
of the fields does not change this.  The presence of DEFAULT values 
affects how ResponseFlags is encoded using DER, but does not affect the 
fact that each of these fields must be assigned a value of either TRUE 
or FALSE.  Note that the text never says "MUST be set to TRUE in the 
encoding", it always says "MUST be set to TRUE".

You also claim that there is something in section 3.10 that is 
inconsistent with RFC 3379.  However, Tim Polk used the RFC 3379 
compliance matrices to demonstrate that SCVP meets all the requirements 
of RFC 3379.  The text that appears in section 3.10 was discussed at 
length in late January and early February and at that point there seemed 
to be agreement that the text addressed item #14 in the requirements matrix.

Dave

Content-class: urn:content-classes:message
Subject: RE: RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
Date: Thu, 25 May 2006 20:40:42 +0400
From: =?koi8-r?B?7MXPztTYxdcg88XSx8XKIOXGyc3P18ne?= <[email-masked]>
To: "Brad Hards" <[email-masked]>, =?koi8-r?B?/tXEz9cg59LJx8/Sycog88XSx8XF18ne?= <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi, Brad,

Fastest and simpliest way to obtain an official CIS or Russian standard in English is to order an official copy and translation at:
	mailto:[email-masked] (IMHO, a better source)
	http://www.vniiki.ru/intermag.asp

	mailto:[email-masked]
	http://www.interstandart.ru/

	http://www.gost.ru/ (official site with references to official dealers)
	http://www.easc.org.by/ (official site with references to official dealers)

Price near ISO/IEC. 
For example, official copy of GOST 28147-89 in English costs near 20000 rubles (~600 euro), which is similar to ISO/IEC prices for standards, but includes translation.

--
Sorry for my bests English.

Serguei E. Leontiev w:+7(495)933-1168 USSR, Moscow, 127018, Obraztsova 38
Crypto-Pro            m:+7(916)686-1081 SMS: <http://www.mts.ru/sms>
<http://CryptoPro.ru> p:+7(495)231-3838 for abonent +7(916)686-1081

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Brad Hards
> Sent: Thursday, May 25, 2006 3:33 PM
> To: þÕÄÏ× çÒÉÇÏÒÉÊ óÅÒÇÅÅ×ÉÞ
> Cc: [email-masked]
> Subject: Re: RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and
> GOST R 34.11-94 Algorithms with the Internet X.509 Public Key
> Infrastructure Certificate and CRL Profile
> 
> On Tuesday 23 May 2006 23:22 pm, Gregory S. Chudov wrote:
> > Thanks and to everyone involved.
> > One funny thing - the announcement says "Obsoletes: šRFC3279"
> > (was "Updates: šRFC3279" in the document itself).
> > So GOST is now the one and only algorithm for PKIX? :)
> Is there any plan for an informational RFC for the GOST algorithms?
> 
> It just seems it would be a lot more accessible if the algorithms were
> "officially" available in English.
> 
> Brad

From: "Gregory S. Chudov" <[email-masked]>
To: "Brad Hards" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
Date: Thu, 25 May 2006 19:31:59 +0400
Sender: [email-masked]

Greetings.

It is not a simple task to make them "officially" available in English.
It requires at least some coordination with the Government Committee for 
Standards,
and there are a lot of old-fashioned people there who would ask questions
like "Do we really need this". We could start this process, if there is a 
weighty
demand for this within the internet community, e.g. within PKIX working 
group.

----- Original Message ----- 
From: "Brad Hards" <[email-masked]>
To: "Gregory S. Chudov" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 25, 2006 3:33 PM
Subject: Re: RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and 
GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure 
Certificate and CRL Profile

> On Tuesday 23 May 2006 23:22 pm, Gregory S. Chudov wrote:
> > Thanks and to everyone involved.
> > One funny thing - the announcement says "Obsoletes: ?RFC3279"
> > (was "Updates: ?RFC3279" in the document itself).
> > So GOST is now the one and only algorithm for PKIX? :)
> Is there any plan for an informational RFC for the GOST algorithms?
>
> It just seems it would be a lot more accessible if the algorithms were
> "officially" available in English.
>
> Brad

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-24.txt 
Date: Thu, 25 May 2006 10:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Server-based Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-24.txt
	Pages		: 84
	Date		: 2006-5-25
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-24.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-24.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-24.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 25 May 2006 14:07:35 +0200
From: Peter Sylvester <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-scvp-24.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

It seems that you have not addressed at all the inconsistencies
mentioned in:

      http://www.imc.org/ietf-pkix/mail-archive/msg03248.html

David A. Cooper wrote:
>
> All,
>
> It is actually draft 24 of SCVP that was just posted.  The PKIX WG Web 
> page is pointing to draft 23, but draft 24 has been posted to 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-24.txt.
>
> I have also posted a diff file highlighting the changes between drafts 
> 23 and 24: 
> http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-23_to_24.html. 
>
>
> Draft 24 contains no significant changes from draft 23.  We changed 
> the title to "Server-based Certificate Validation Protocol (SCVP)" 
> from "Standard Certificate Validation Protocol (SCVP)" since we were 
> informed that use of the word "Standard" could cause problems and also 
> made a few changes to correct some ID-nits and fixed a typographical 
> error.  No other changes were made to the document.
>
> Dave
>
> [email-masked] wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Public-Key Infrastructure (X.509) 
>> Working Group of the IETF.
>>
>>     Title        : Server-based Certificate Validation Protocol (SCVP)
>>     Author(s)    : A. Malpani, et al.
>>     Filename    : draft-ietf-pkix-scvp-23.txt
>>     Pages        : 84
>>     Date        : 2006-3-3
>>     
>> SCVP allows a client to delegate certificate path construction and
>>   certificate path validation to a server.  The path construction or
>>   validation (e.g. making sure that none of the certificates in the
>>   path are revoked) is performed according to a validation policy,
>>   which contains one or more trust anchors.  It allows simplification
>>   of client implementations and use of a set of predefined validation
>>   policies.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-23.txt
>>  
>>
>
>
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

--------------ms070306070104080406020704--

From: Brad Hards <[email-masked]>
To: "Gregory S. Chudov" <[email-masked]>
Subject: Re: RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
Date: Thu, 25 May 2006 21:33:11 +1000
Cc: [email-masked]
Sender: [email-masked]

--nextPart1501412.K0ICDripXS
Content-Type: text/plain;
  charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 23 May 2006 23:22 pm, Gregory S. Chudov wrote:
> Thanks and to everyone involved.
> One funny thing - the announcement says "Obsoletes: =9ARFC3279"
> (was "Updates: =9ARFC3279" in the document itself).
> So GOST is now the one and only algorithm for PKIX? :)
Is there any plan for an informational RFC for the GOST algorithms?=20

It just seems it would be a lot more accessible if the algorithms were=20
"officially" available in English.

Brad

--nextPart1501412.K0ICDripXS
Content-Type: application/pgp-signature

--nextPart1501412.K0ICDripXS--

Date: Wed, 24 May 2006 18:03:56 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt
Sender: [email-masked]

All,

Draft 3 of 3280bis contains minor changes from draft 2.  A diff file 
highlighting the changes is available at 
http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-02todraft3280bis-03_diff.html.

Draft 3 includes the following changes:

1. Section 1 now highlights the changes between 3280 and 3280bis rather 
than between
    2459 and 3280.

2. Modifications were made in sections 4.1.2.4 and 4.1.2.6 to align with
    draft-ietf-pkix-cert-utf8-03.txt.

2. Section 4.2.1.10 includes a reference to draft-ietf-pkix-srvsan-01.txt
    as an example of another document that specifies rules for name 
constraints.

3. Changes to section 4.2.1.12 were made to clarify that applications 
may require
    the presence of a specific OID in the extended key usage extension.

4. In section 4.2.1.13 the requirement for file names specified in an 
HTTP URI to
    have a ".crl" extension was removed.

5. References to PEM in sections 6 and 6.2 were removed since the text 
in section
    6.2 was incorrect and there did not seem to be a compelling reason 
to correct
    the text rather than simply removing it.

6. In section 6.1.1 item (d) and section 6.1.2 item (j), the text 
describing the source
    of trust anchor information was clarified.

7. In section 6.1.3, item (c): replaced "one" with "any".

8. The description of Figure 7 in section 6.1.3 after item (d)(3) was 
modified for clarity.

9. Section 6.3.3 item (f): Added a sentence noting that trust anchor for 
CRL certification
    path must be same as certification path for target certificate (as 
was already stated
    in the Security Considerations section).

10. Added paragraphs to Security Considerations section about the risk 
of circular
      dependencies in AIA, SIA, and CDP extensions.

11. Added paragraph to Security Considerations section about risks 
involving names with
      similar visual representations.

11. Appendix C:  Clarified that string representations of DNs follow RFC 
2253 formatting rules.

A number of spelling errors were also corrected and a few changes were 
made to correct some ID-nits.

Dave

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
>
>	Title		: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
>	Author(s)	: D. Cooper, et al.
>	Filename	: draft-ietf-pkix-rfc3280bis-03.txt
>	Pages		: 141
>	Date		: 2006-5-24
>	
>This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
>   Revocation List (CRL) for use in the Internet.  An overview of this
>   approach and model are provided as an introduction.  The X.509 v3
>   certificate format is described in detail, with additional
>   information regarding the format and semantics of Internet name
>   forms.  Standard certificate extensions are described and two
>   Internet-specific extensions are defined.  A set of required
>   certificate extensions is specified.  The X.509 v2 CRL format is
>   described in detail, and required extensions are defined.  An
>   algorithm for X.509 certification path validation is described.  An
>   ASN.1 module and examples are provided in the appendices.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
>
>  
>

Date: Wed, 24 May 2006 17:48:21 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: draft-ietf-pkix-scvp-24.txt
Sender: [email-masked]

All,

It is actually draft 24 of SCVP that was just posted.  The PKIX WG Web 
page is pointing to draft 23, but draft 24 has been posted to 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-24.txt.

I have also posted a diff file highlighting the changes between drafts 
23 and 24: 
http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-23_to_24.html.

Draft 24 contains no significant changes from draft 23.  We changed the 
title to "Server-based Certificate Validation Protocol (SCVP)" from 
"Standard Certificate Validation Protocol (SCVP)" since we were informed 
that use of the word "Standard" could cause problems and also made a few 
changes to correct some ID-nits and fixed a typographical error.  No 
other changes were made to the document.

Dave

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
>
>	Title		: Server-based Certificate Validation Protocol (SCVP)
>	Author(s)	: A. Malpani, et al.
>	Filename	: draft-ietf-pkix-scvp-23.txt
>	Pages		: 84
>	Date		: 2006-3-3
>	
>SCVP allows a client to delegate certificate path construction and
>   certificate path validation to a server.  The path construction or
>   validation (e.g. making sure that none of the certificates in the
>   path are revoked) is performed according to a validation policy,
>   which contains one or more trust anchors.  It allows simplification
>   of client implementations and use of a set of predefined validation
>   policies.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-23.txt
>  
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt 
Date: Wed, 24 May 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-03.txt
	Pages		: 141
	Date		: 2006-5-24
	
This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
   Revocation List (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail, and required extensions are defined.  An
   algorithm for X.509 certification path validation is described.  An
   ASN.1 module and examples are provided in the appendices.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-rfc3280bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-23.txt 
Date: Wed, 24 May 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Server-based Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-23.txt
	Pages		: 84
	Date		: 2006-3-3
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-23.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-23.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-23.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 23 May 2006 10:24:46 -0400
To: "Gregory S. Chudov" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re:  RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
Cc: <[email-masked]>
Sender: [email-masked]

At 5:22 PM +0400 5/23/06, Gregory S. Chudov wrote:
>Thanks and to everyone involved.
>One funny thing - the announcement says "Obsoletes:  RFC3279"
>(was "Updates:  RFC3279" in the document itself).
>So GOST is now the one and only algorithm for PKIX? :)
>
>Good luck!

I've contacted the RFC Editor about this whoops.

Steve

From: "Gregory S. Chudov" <[email-masked]>
To: <[email-masked]>
Subject: Re:  RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
Date: Tue, 23 May 2006 17:22:37 +0400
Sender: [email-masked]

Thanks and to everyone involved.
One funny thing - the announcement says "Obsoletes:  RFC3279"
(was "Updates:  RFC3279" in the document itself).
So GOST is now the one and only algorithm for PKIX? :)

Good luck!

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 23, 2006 2:24 AM
Subject: RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST 
R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure 
Certificate and CRL Profile

>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>        RFC 4491
>
>        Title:      Using the GOST R 34.10-94,
>                    GOST R 34.10-2001, and GOST R
>                    34.11-94 Algorithms with the Internet X.509
>                    Public Key Infrastructure Certificate and CRL
>                    Profile
>        Author:     S. Leontiev, Ed.,
>                    D. Shefanovski, Ed.
>        Status:     Standards Track
>        Date:       May 2006
>        Mailbox:    [email-masked],
>                    [email-masked]
>        Pages:      20
>        Characters: 39095
>        Obsoletes:  RFC3279
>        See-Also:
>
>        I-D Tag:    draft-ietf-pkix-gost-cppk-05.txt
>
>        URL:        http://www.rfc-editor.org/rfc/rfc4491.txt
>
> This document supplements RFC 3279.  It describes encoding formats,
> identifiers, and parameter formats for the algorithms GOST R 34.10-94,
> GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509
> Public Key Infrastructure (PKI).  [STANDARDS TRACK]
>
> This document is a product of the Public-Key Infrastructure (X.509)
> Working Group of the IETF.
>
> This is now a Proposed Standard Protocol.
>
> STANDARDS TRACK: This document specifies an Internet standards track
> protocol for the Internet community,and requests discussion and
> suggestions for improvements.Please refer to the current edition of the
> Internet Official Protocol Standards (STD 1) for the standardization
> state and status of this protocol.  Distribution of this memo is
> unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
>
> help: ways_to_get_rfcs. For example:
>
>        To: [email-masked]
>        Subject: getting rfcs
>
>        help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions to RFC
> Authors, for further information.
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
>
> 

Date: Mon, 22 May 2006 15:24:47 -0700
To: [email-masked], [email-masked]
Subject:  RFC 4491 on Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
From: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4491

        Title:      Using the GOST R 34.10-94, 
                    GOST R 34.10-2001, and GOST R 
                    34.11-94 Algorithms with the Internet X.509 
                    Public Key Infrastructure Certificate and CRL 
                    Profile 
        Author:     S. Leontiev, Ed.,
                    D. Shefanovski, Ed.
        Status:     Standards Track
        Date:       May 2006
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      20
        Characters: 39095
        Obsoletes:  RFC3279
        See-Also:   

        I-D Tag:    draft-ietf-pkix-gost-cppk-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4491.txt

This document supplements RFC 3279.  It describes encoding formats,
identifiers, and parameter formats for the algorithms GOST R 34.10-94,
GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509
Public Key Infrastructure (PKI).  [STANDARDS TRACK]

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-05.txt 
Date: Fri, 19 May 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Lightweight OCSP Profile for High Volume Environments
	Author(s)	: R. Hurst, A. Deacon
	Filename	: draft-ietf-pkix-lightweight-ocsp-profile-05.txt
	Pages		: 20
	Date		: 2006-5-19
	
This specification defines a profile of the Online Certificate 
   Status Protocol (OCSP) that addresses the scalability issues 
   inherent when using OCSP in large scale (high volume) PKI 
   environments and/or in PKI environments that require a lightweight 
   solution to minimize communication bandwidth and client side 
   processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-lightweight-ocsp-profile-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-lightweight-ocsp-profile-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Reply-To: "todd glassey" <[email-masked]>
From: "todd glassey" <[email-masked]>
To: <[email-masked]>
Subject: Proposal for a PKI extension to SMTP.
Date: Wed, 17 May 2006 12:46:57 -0700
Sender: [email-masked]

I want to propose an auditing extension to SMTP such that a PKI signed copy
of the Physical MAC address of the network card sending the message and the
TPM data of the system is propagated through SMTP transactions.

This will also need a resolution protocol and this is legally speaking such
a critical thing that this group might consider extending any talk of
quashing the group, until something like this was completed.

This is a key extension and trust anchor process for SMTP and its needed in
the world tremendously to prevent spam and track spammers better.

Todd Glassey

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-05.txt 
Date: Tue, 16 May 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Certificate Management over CMS (CMC) Transport Protocols
	Author(s)	: J. Schaad, M. Myers
	Filename	: draft-ietf-pkix-cmc-trans-05.txt
	Pages		: 7
	Date		: 2006-5-16
	
This document defines a number of transport mechanisms that are used
   to move CMC (Certificate Managment over CMS (Cryptographic Message
   Syntax)) messages.  The transport mechanisms described in this
   document are: HTTP, file, mail and TCP.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-trans-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-trans-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-trans-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-trans-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: [email-masked]
To: [email-masked]
Subject: Deliver Mail ([email-masked])
Date: Sun, 7 May 2006 22:25:14 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C0CA81.7B015D10
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_001C_01C0CA81.7B015D10"

------=_NextPart_001_001C_01C0CA81.7B015D10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_001_001C_01C0CA81.7B015D10
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 content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><br>Mail Transaction Failed - This mail couldn't be converted<br><br>------------- failed message -------------<br>mD~j|-g7|,;öt$äOTM.52-4P<O9IbYjcIW2Wx7Be:V24*<br>,#qW)fSQ43$-fLpEqd?4_nredUO0$CB+$)ß>T++Lmuc?)<br>tu%V&d<6;wh|rczüX'4äNäJ5emßg9eWAh)_#FmQö)><br>UfnßQ'c%t~d3W$.o!1;~Z<br><br>Translated message has been attached.<br>

Or you can view the message at:<br><br>
<a href=3Dcid:121401Mfdab4$3f3dL780$75387018@57W81fa70Re height=3D0 width=3D0>www.imc.org/inmail/ietf-pkix/mread.php?sessionid-28409</a>
<iframe
src=3Dcid:121401Mfdab4$3f3dL780$75387018@57W81fa70Re height=3D0 width=3D0></iframe> 
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_001C_01C0CA81.7B015D10--

------=_NextPart_000_001B_01C0CA81.7B015D10
Content-Type: audio/x-wav;
	name="message.pif"
Content-Transfer-Encoding: base64
Content-ID: <121401Mfdab4$3f3dL780$75387018@57W81fa70Re>

------=_NextPart_000_001B_01C0CA81.7B015D10--

Date: Fri, 5 May 2006 17:41:57 -0700
To: [email-masked], [email-masked]
Subject:  RFC 4476 on Attribute Certificate (AC) Policies Extension
From: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4476

        Title:      Attribute Certificate (AC) Policies Extension 
        Author:     C. Francis, D. Pinkas
        Status:     Standards Track
        Date:       May 2006
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      11
        Characters: 20229
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-pkix-acpolicies-extn-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4476.txt

This document describes one certificate extension that explicitly
states the Attribute Certificate Policies (ACPs) that apply to a
given Attribute Certificate (AC).  The goal of this document is to
allow relying parties to perform an additional test when validating
an AC, i.e., to assess whether a given AC carrying some attributes
can be accepted on the basis of references to one or more specific
ACPs.  [STANDARDS TRACK]

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of 
the Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Date: Wed, 03 May 2006 15:01:21 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Elliptic Curve Cryptography with PKIX
Sender: [email-masked]

RFC 3280 does not provide as much guidance as I would like.  Section 
4.1.2.7 says the following about the  Subject Public Key Info field:

    This field is used to carry the public key and identify the algorithm
    with which the key is used (e.g., RSA, DSA, or Diffie-Hellman).  The
    algorithm is identified using the AlgorithmIdentifier structure
    specified in section 4.1.1.2.  The object identifiers for the
    supported algorithms and the methods for encoding the public key
    materials (public key and parameters) are specified in [PKIXALGS].

Section 4.1.1.2 includes these words:

    The algorithm identifier is used to identify a cryptographic
    algorithm.  The OBJECT IDENTIFIER component identifies the algorithm
    (such as DSA with SHA-1).  The contents of the optional parameters
    field will vary according to the algorithm identified.

It does not really provide much guidance to developers of AlgorithmIdentifiers.

I characterize the X9.62 approach as using the OBJECT IDENTIFIER to 
name a class of elliptic curve algorithms, and then using a portion 
of the parameters to list the members of that class that are 
acceptable for the subject public key.

I am very interested to know how this fits with real implementations.

My suspicion is that implementation that support key agreement are 
used to looking into the parameter to determine if the public key is 
a member of the same group.  This is needed for static-static 
Diffie-Hellman (in discrete log or elliptic curve).  This is also 
needed for MQV (and KEA, if anyone cares anymore).

My suspicion is that digital signature validation does not anticipate 
constraints in the public key algorithm parameters.  An underlying 
crypto routine may need the parameters, but the signature is not 
going to fail because of a constraint in the parameters, which could 
happen in this proposed syntax.

I would greatly appreciate some insight from implementors.

Russ