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

I have no objections to making these changes.

Steve
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

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

At 9:34 PM +0200 8/31/09, Stefan Santesson wrote:
>I'm OK with the change.
>

At 7:51 PM -0400 8/31/09, Stephen Kent wrote:
>I have no objections to making these changes.
>

Just to be clear: both of you are fine with us changing the modules *for RFC 3281* to be different than what is
in that RFC?

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

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

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" <phoffman <at> imc.org> wrote:

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

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

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" <phoffman <at> imc.org> wrote:

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

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

I-D Action:draft-ietf-pkix-rfc3161-update-02.txt

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

	Title           : ESSCertIDv2 update for RFC 3161
	Author(s)       : S. Santesson, N. Pope
	Filename        : draft-ietf-pkix-rfc3161-update-02.txt
	Pages           : 10
	Date            : 2009-09-07

This document updates RFC 3161 [RFC3161]. It allows the use of
ESSCertIDv2 defined in RFC 5035 [ESSv2] to specify the hash of a
signer certificate when the hash is calculated with a function other
than SHA-1 [SHA1].

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

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

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

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           : ESSCertIDv2 update for RFC 3161

I-D Action:draft-ietf-pkix-rfc3161-update-03.txt

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

	Title           : ESSCertIDv2 update for RFC 3161
	Author(s)       : S. Santesson, N. Pope
	Filename        : draft-ietf-pkix-rfc3161-update-03.txt
	Pages           : 10
	Date            : 2009-09-08

This document updates RFC 3161 [RFC3161]. It allows the use of
ESSCertIDv2 defined in RFC 5035 [ESSv2] to specify the hash of a
signer certificate when the hash is calculated with a function other
than SHA-1 [SHA1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161-update-03.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.

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           : ESSCertIDv2 update for RFC 3161

[pkix] draft-dolmatov-dnsext-dnssec-gost-01 technical & editorial issues (fwd)

Folks,
I apologize for cross-posting, but the following excerpt of my
post to namedroppers might be of interest for PKIX and SMIME,
the originators of RFCs 4490 and 4491, for which I have filed
Errata -- in part to solicit discussion.

The full message is archived at:
  http://ops.IETF.ORG/lists/namedroppers/namedroppers.2009/msg02525.html

----- Forwarded message -----

> From: Alfred Hönes <ah <at> TR-Sys.de>
> To: dol <at> cryptocom.ru, ran <at> cryptocom.ru, igus <at> cryptocom.ru,
>     namedroppers <at> ops.ietf.org
> Message-Id: <200909171025.MAA15356 <at> TR-Sys.de>
> Subject: draft-dolmatov-dnsext-dnssec-gost-01 technical & editorial issues
> Date: Thu, 17 Sep 2009 12:25:12 +0200 (MESZ)
>
> Folks,
>
> I have reviewed draft-dolmatov-dnsext-dnssec-gost-01 and found
> a number of issues of varying degree of severeness.
> Items (1)..(3) below are the hard stuff, the nits are in (4).
>
>
> (1)
>
> First of all, I'm confused by, and strongly oppose to, the
> introduction of little-endian encoding for the on-the-wire
> encoding of specific elements of this proposal, as requested

[pkix] Guidance on using the same key for key establishment and signing data

I *think* this came up on this list before, but I can't find a 
reference.  Has any standards body (e.g. NIST) published guidance on 
servers using the same keypair for key establishment (e.g., SSL) and 
data signing (e.g. XML-Dsig)?

aTdHvAaNnKcSe.

-- Tim

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Re: [pkix] Guidance on using the same key for key establishment and signing data

Paul Hoffman wrote:

> Do you consider "don't do it" to be guidance? NIST requires that a public key be used for only one purpose in a
handful of their documents. I don't believe that it fully justifies this requirement anywhere, but I
could be wrong. The best reason that I have heard is that most organizations have very different escrow
policies for encryption keys than for signing keys, and having one key do both would muddle the policy. To
me, that's a good enough argument, and it trumps "but I only want to manage one private key".

SSL/TLS using DHE key agreement would only be used the key pair for 
digital signature.  Key encipherment or key agreement would only be 
needed for the DH and RSA key exchange ciphersuites.  In cases where the 
ciphersuite is limited to DHE key exchange, would you agree one key for 
both uses is acceptable?

-- Tim

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Re: [pkix] Guidance on using the same key for key establishment and signing data

At 8:27 AM -0500 9/24/09, Timothy J. Miller wrote:
>I *think* this came up on this list before, but I can't find a reference.  Has any standards body (e.g. NIST)
published guidance on servers using the same keypair for key establishment (e.g., SSL) and data signing
(e.g. XML-Dsig)?

Do you consider "don't do it" to be guidance? NIST requires that a public key be used for only one purpose in a
handful of their documents. I don't believe that it fully justifies this requirement anywhere, but I
could be wrong. The best reason that I have heard is that most organizations have very different escrow
policies for encryption keys than for signing keys, and having one key do both would muddle the policy. To
me, that's a good enough argument, and it trumps "but I only want to manage one private key".
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix