There was an intent to have a virtual meeting of the JOSE WG on
2013-06-17. The announcement never made it to the IETF announce list.
Because of this that virtual meeting is considered a design team meeting
and not an official virtual interim meeting. As such, all output is
subject to
On 6/11/13 8:12 AM, Ted Lemon wrote:
On Jun 11, 2013, at 7:52 AM, Måns Nilsson mansa...@besserwisser.org wrote:
So, if wg discussion has been ordered mute by the wg chairs because
some wg participants believe the group-think consensus is good enough,
can those objections again be raised in IETF
On 6/11/13 4:30 AM, SM wrote:
At 07:45 10-06-2013, The IESG wrote:
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Enrollment over Secure Transport'
draft-ietf-pkix-est-07.txt as Proposed Standard
The IESG plans to
On 3/27/13 5:35 PM, Denis wrote:
First of all, this is an announcement: I am retiring from Bull at the
end of this week, this why I am now using a new email address.
Hopefully, you'll still find time in your retirement to keep on PKIXing!
The second announcement is that I am taking one full
Martin,
I went all the way to Sam's original message about his discuss on the
draft that became RFC 5019:
https://www.ietf.org/mail-archive/web/pkix/current/msg03627.html
and reviewed the 60 or so messages in the thread.
Aside: I think when you're referring to updating RFC 5019 you're
On 3/25/13 10:21 PM, Stefan Santesson wrote:
Hi David,
Nits:
idnits 2.12.15 said:
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If
you
have contacted all the original authors and they are
Based on IETF LC comments, I'm returning this draft to the WG. Stay
tuned for another IETF LC in a couple of weeks.
spt
On 8/22/12 11:05 AM, The IESG wrote:
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Updates to
Steve/Sam,
I've gone ahead and entered fixes for these two as RFC editor notes to
ensure we won't forget them.
Thanks for working through this!
spt
On 5/24/12 9:07 AM, Stephen Hanna wrote:
Sam,
Thanks for addressing my comments in draft-ietf-emu-chbind-16.txt.
I'm happy with this version.
I use: http://datatracker.ietf.org/doc/
and tick the expired/replace/withdrawn button
spt
On 9/30/11 10:43 AM, Adrian Farrel wrote:
Hi Tony,
It was taken down after the earthquake as a power saving measure.
I miss it too.
however, the tools archive is pretty good.
A
-Original
On 7/25/11 2:01 PM, Dave CROCKER wrote:
On 7/25/2011 1:17 PM, Glen wrote:
I am very pleased to report that the IETF is now applying DKIM signatures
to all outgoing list email from mailman.
I'll be presumptuous and speak on behalf of the DKIM operations
community, rather than just myself:
The IESG is considering making this statement on the IESG Handling of
Historic status.
We would appreciate community feedback.
Please can we have feedback by Thursday 9th June.
Thanks
spt
statement begins
RFC 2026 states the following:
A specification that has been superseded by a more
On 5/11/11 2:28 AM, SM wrote:
At 13:43 09-05-2011, The IESG wrote:
The IESG has received a request from the isms WG (isms) to consider the
following document:
- 'Transport Layer Security (TLS) Transport Model for the Simple Network
Management Protocol (SNMP) '
RFC 5953 as a Draft Standard
Two
On 2/28/11 3:45 AM, Nikos Mavrogiannopoulos wrote:
On Mon, Feb 28, 2011 at 7:35 AM, Satoru Kanno
kanno.sat...@po.ntts.co.jp wrote:
I see that this document defines ciphersuites with a PRF based on
SHA384... However it does not specify the verify_data_length, thus
the default value of 12
On Feb 21, 2011, at 1:15 PM, Christopher Morrow morrowc.li...@gmail.com wrote:
(not speaking for the authors, just observing some... also not
speaking as a co-chair)
On Mon, Feb 21, 2011 at 11:23 AM, t.petch daedu...@btconnect.com wrote:
I find this I-D problematic. The subject matter is
Wes,
I'm sympathetic to your concern, but I also think we need to specify
that this particular use needs to be in-line with the protocol (as
noted by Sam). How about the following changes in the introduction:
OLD:
[HASH-Attack] summarizes the use of hashes in many protocols and
discusses
On 12/10/10 6:09 PM, Marsh Ray wrote:
On 12/10/2010 03:35 PM, Sean Turner wrote:
On 12/3/10 3:27 PM, Sean Turner wrote:
negotiate means returning a ServerHello handshake message with that
version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3
ServerHello with a server version
On 12/3/10 3:27 PM, Sean Turner wrote:
On 12/3/10 2:58 PM, Martin Rex wrote:
Glen Zorn wrote:
Martin Rex wrote:
Glen Zorn wrote:
Maybe I just don't understand the word use. It seems like if a
server accepts a protocol message it's using the protocol...
With negotiate I meant returning
On 12/1/10 5:53 PM, l.w...@surrey.ac.uk wrote:
forwarding comments as per last call request.
Lloyd Wood
http://tinyurl.com/lloydwood-ccsr
From: Wood L Dr (Electronic Eng)
Sent: 01 December 2010 07:56
To: turn...@ieca.com; lily.c...@nist.gov;
in the draft just as you have above?
I'm sorry, my explanations were misleading. I explained what I meant
when I wrote these statements that ended up in the document.
http://www.ietf.org/mail-archive/web/tls/current/msg07091.html
The author/editor of this I-D is Sean Turner.
I've got
I'd offered to review this version during the TLS session at IETF 78,
but I think I'm going to wait for the next version ;)
spt
Wes Hardaker wrote:
I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good
document and support it's forward progress. I do have a few comments
I like:
Be conservative in what you send and liberal in what you accept
Jon Postel
I'm sure somebody who has been around longer than me can offer up a
date ;)
spt
Fred Baker wrote:
There's no place like ::1
On Aug 16, 2010, at 2:01 PM, Philip Nesser wrote:
We obviously
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Random Extension to TLS '
draft-hoffman-tls-additional-random-ext-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
Suresh Krishnan wrote:
5) draft-ietf-sidr-res-certs-17 is expired.
We need to normatively reference this draft. So I guess we will get
stuck in the RFC-Ed Queue waiting for this.
I just noticed the draft-ietf-sidr-arch-09 is also expired.
spt
The IESG wrote:
The IESG has received a request from the Cga Send maIntenance WG (csi)
to consider the following document:
- 'SEND Name Type field Registry '
draft-ietf-csi-send-name-type-registry-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
Suresh Krishnan wrote:
Hi Sean,
I will make the changes to the IANA considerations section like you
suggested. I think it adds clarity about the required assignment.
On 10-05-01 06:56 AM, Sean Turner wrote:
Suresh,
4.c) Was there discussion about support for the anyExtendedKeyUsage
OID
Suresh,
Responses inline. I deleted the ones we've agreed on.
spt
Suresh Krishnan wrote:
3) Technically your IANA considerations is wrong because you need to
get OIDs. Might I suggest something like:
This document makes use of object identifiers to identify a Extended
Key Usages
Simon Josefsson wrote:
Sam Hartman hartmans-i...@mit.edu writes:
Simon == Simon Josefsson si...@josefsson.org writes:
Simon This document appears to have a normative reference to a
Simon patent:
Simon[LUHN] Luhn, H., Luhn algorithm, US Patent 2950048,
Simon August 1960,
Roni,
Thanks for your review. Comments inline.
spt
Roni Even wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your
we wouldn't have collisions. The
earlier versions of the ID had tbd as place holders until I officially
got them registered.
spt
Thanks
Roni Even
-Original Message-
From: Sean Turner [mailto:turn...@ieca.com]
Sent: Sunday, April 18, 2010 8:37 PM
To: Roni Even
Cc: 'General Area Review
Dave CROCKER wrote:
On 3/11/2010 7:32 AM, Donald Eastlake wrote:
Periodically, there are flame wars on the IETF mailing list that the
IETF should / shouldn't...
Mayhap we should create a FAQ wiki that captures the essence of these
debates, so that we can simply cite the relevant entry
Alfred � wrote:
At Thu, 4 Mar 2010 15:36:03 -0700, Cullen Jennings wrote:
I was just looking at this draft and thinking about the IANA
registration for the application/pkcs8 media type. Right now that
registration is in draft-ietf-sip-certs draft which this draft
references. When you think
Alfred,
I didn't forget about these. Responses inline.
spt
Alfred � wrote:
I have taken a closer look at draft-ietf-smime-cms-rsa-kem-10
and will send another detailed editorial review to the authors.
Below are my more significant comments and questions:
(A)
Shouldn't this memo be updated
Edward Lewis wrote:
At 10:57 -0500 2/12/10, Stephen Kent wrote:
If we look at what the CP developed in the SIDR WG for the RPKI says, the
answer is the IESG (going forward, after an initial set of algs are
adopted
based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts,
the WGs
Michael Dillon wrote:
One of the problems with GOST is its lack of availability of
documentation/specification and the meaning, purpose and
characteristics of algorithm parameters.
A bit of Googling turned up this http://vsegost.com/Catalog/96/9658.shtml
with scanned GIFs of ГОСТ Р34.10-1994.
Martin Rex wrote:
Sean Turner wrote:
Is the real problem the lack of English language documentation?
If so, I'm sure that the people who would like to use these algorithms
could arrange for translations of the two documents, and perhaps even
make that an individual submission as an Internet
-
From: Sean Turner [mailto:turn...@ieca.com]
Sent: Thursday, 3 September 2009 3:41 AM
To: Andrew Sciberras (GMAIL)
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-turner-deviceowner-attribute (Device
OwnerAttribute) to Informational RFC
Andrew,
Thank for taking the time to review the draft
Stefan,
If you find out what's up I'd be curious to know what the issue is/was.
My delays are in the more range over the last couple of days.
spt
Stefan Santesson wrote:
I and others have experienced unusually long delays from posting messages to
various ietf mailing lists lately.
4-5
Andrew,
Thank for taking the time to review the draft. Responses inline.
spt
Andrew Sciberras (GMAIL) wrote:
Hello
I have a few minor comments:
1.
The definition of the deviceOwner attribute in section 2 indicates:
IDENTIFIED BY id-deviceOwner
This should be updated to
Julian Reschke wrote:
SM wrote:
Hello,
I was discussing RFC 5617 with someone and the person mentioned that
the copyright in the middle of the document is obnoxious. The
copyright statement for the code is 32 lines while the code (ABNF) is
only five lines.
If an author wants to include
Julian Reschke wrote:
Sean Turner wrote:
...
In the documents I've worked on, it seems that they just want to put
the statement in the section that collects all the ABNF, ASN.1, XML, etc.
...
Who is they, and how is that consistent with what Joel just told us?
This might be overtaken
Doug,
Thanks for the quick reply.
Douglas Stebila wrote:
On 2009-Jun-9, at 11:25 AM, Sean Turner wrote:
Other ECC documents in the IETF (TLS, SMIME, PKIX) indicate that
support for compressed keys are MAY while this draft says MUST NOT for
ECDSA and ECDH keys and MAY for ECMQV. What
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport
Layer '
draft-green-secsh-ecc-08.txt as an Informational RFC
The IESG plans to make a decision in the
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Suite B Certificate and Certificate Revocation List (CRL) Profile '
draft-solinas-suiteb-cert-profile-03.txt as an Informational RFC
The IESG plans to make a decision in the
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Guidance on Interoperation and Implementation Reports '
draft-dusseault-impl-reports-02.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
Can we add two ASN.1 modules. They should include the OIDs and one
should define the algs the old way (e.g., RFC 3370) and the other should
define the algs the new way (draft-ietf-smime-new-asn1-05.txt)? I would
really like the OIDs in a module, as not having OIDs in a module has
caused
45 matches
Mail list logo