Sean Turner | 1 May 2010 12:56

Re: Last Call: draft-ietf-csi-send-cert (Certificate profile and certificate management for SEND) to Proposed Standard

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 (EKUs) and the ASN.1 module found in Appendix *TBD*.  The
>>    EKUs and ASN.1 module OID are registered in an arc delegated by IANA
>>    to the PKIX Working Group.  No further action by IANA is necessary for
>>    this document or any anticipated updates.
> 
> Given 2) is it OK to leave this section as it is?

It's up to you whether you want to keep the text as is.

>> 4.c) Was there discussion about support for the anyExtendedKeyUsage 
>> OID from 4.2.1.12 of RFC 5280?
> 
> No. I am not sure it would be useful as the SEND implementations really 
> need to know the EKU to work properly. The packet processing is based on 
> the value of the EKU.

Hmmm if you're not going to support it, then you might want to 
put some text in about it not being allowed.  5280 allows 
(Continue reading)

Sean Turner | 3 May 2010 14:31

Re: Last Call: draft-ietf-csi-send-cert (Certificate profile and certificate management for SEND) to Proposed Standard

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 from 4.2.1.12 of RFC 5280?
>>> No. I am not sure it would be useful as the SEND implementations 
>>> really need to know the EKU to work properly. The packet processing 
>>> is based on the value of the EKU.
>>
>> Hmmm if you're not going to support it, then you might want to put 
>> some text in about it not being allowed.  5280 allows applications to 
>> reject certificates that include this extension.
> 
> OK. I will add the following text at the end of Section 7
> 
> "Certificate-using applications MUST reject certificates that do not 
> contain one of the three KeyPurposeIds defined above even if they 
> include the anyExtendedKeyUsage OID defined in [RFC5280]."
> 
> Does this work?

That would work for me.

spt
todd glassey | 3 May 2010 17:28
Picon
Favicon

Formal SPAM Compliant filed against Anderson...

Folks - I have had it with Dean and his actions in spamming me after
being thrown off of IETF lists.

Mr. Anderson has created a set of IETF mirror lists which he calls
"IETF-Honest" and which he subscribes IETF members to against their will
after being told numerous times to cease and desist.

Obviously the only recourse is a formal spam compliant with the FTC so
the first complaint's filing number is 26303937.

I would encourage all of you - and I mean all of you who are as annoyed
with this spamming as I am to visit the FTC website and file your own
complaint as if there are 10 or 20 of them independently filed, the FTC
will in fact take action on this abuse.

http://www.ftc.gov/spam

Have a nice day.

Todd Glassey
Attachment (tglassey.vcf): text/x-vcard, 125 bytes
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Phillip Hallam-Baker | 1 May 2010 17:13
Picon

Re: [KEYPROV] Second Last Call: draft-ietf-keyprov-symmetrickeyformat (Symmetric Key Package Content Type) to Proposed Standard

I am not sure if the reference is definitively normative. Looks to me
as if implementers can implement without reading the Luhn patent

However, ISO/IEC 7812 is the same as the Luhn patent so how about we
make [LUHN] informative and Annex B of ISO/IEC 7812 normative?

       o checkDigit indicates whether a device needs to check the
        appended Luhn check digit, as defined in [LUHN], contained in a
        challenge.  The checkDigit MUST NOT be present if the encoding
        value is anything other than 'DECIMAL'.  A value of TRUE
        indicates that the device will check the appended Luhn check
        digit in a provided challenge.  A value of FALSE indicates that
        the device will not check the appended Luhn check digit in the
        challenge.

On the downref issue, the binary format is being used in real code so
should not be considered experimental at this point in my view. I
would like to see the binary time RFC upgraded to standard.
On Wed, Apr 28, 2010 at 4:12 PM, Sam Hartman <hartmans-ietf <at> mit.edu> wrote:
>>>>>> "Simon" == Simon Josefsson <simon <at> 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, http://patft.uspto.gov/netacgi/nph-
>    Simon> Parser?patentnumber=2950048.
>
>    Simon> I cannot find a patent disclosure about this on file with the
>    Simon> IETF:
(Continue reading)

Joe Baptista | 3 May 2010 19:25

Re: Formal SPAM Compliant filed against Anderson...

I think Dean does a good job of keeping the IETF honest.

cheers
joe baptista

On Mon, May 3, 2010 at 11:28 AM, todd glassey <tglassey <at> earthlink.net> wrote:
Folks - I have had it with Dean and his actions in spamming me after
being thrown off of IETF lists.

Mr. Anderson has created a set of IETF mirror lists which he calls
"IETF-Honest" and which he subscribes IETF members to against their will
after being told numerous times to cease and desist.

Obviously the only recourse is a formal spam compliant with the FTC so
the first complaint's filing number is 26303937.

I would encourage all of you - and I mean all of you who are as annoyed
with this spamming as I am to visit the FTC website and file your own
complaint as if there are 10 or 20 of them independently filed, the FTC
will in fact take action on this abuse.

http://www.ftc.gov/spam

Have a nice day.

Todd Glassey

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




--
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community <at> large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: http://baptista.cynikal.net/
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Peter Saint-Andre | 3 May 2010 19:28
Favicon

Re: Formal SPAM Compliant filed against Anderson...

On 5/3/10 11:25 AM, Joe Baptista wrote:

> I think Dean does a good job of keeping the IETF honest.

If only we could say the same thing about the IETF's effect on Dean.

/psa

Attachment (smime.p7s): application/pkcs7-signature, 6820 bytes
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
John Levine | 3 May 2010 19:42

Re: Formal SPAM Compliant filed against Anderson...

>Obviously the only recourse is a formal spam compliant with the FTC so
>the first complaint's filing number is 26303937.

CAN SPAM only regulates commercial mail.  Dean's mail is incoherent and
annoying, but it's not commercial.

He still uses 130.105/16 that he stole from the OSF and 198.3.136.0/21
that he got in 2004.  Nullrouting those blocks can improve your
quality of life.

R's,
John
todd glassey | 3 May 2010 19:48
Picon
Favicon

Re: Formal SPAM Compliant filed against Anderson...

On 5/3/2010 10:25 AM, Joe Baptista wrote:
> I think Dean does a good job of keeping the IETF honest.
> 
> cheers
> joe baptista

Maybe Joe but I do not want to be a party to his mailing lists, and he
will not allow me off of them, so I have no choice but to file the spam
compliant.

Todd

> 
> On Mon, May 3, 2010 at 11:28 AM, todd glassey <tglassey <at> earthlink.net>wrote:
> 
>> Folks - I have had it with Dean and his actions in spamming me after
>> being thrown off of IETF lists.
>>
>> Mr. Anderson has created a set of IETF mirror lists which he calls
>> "IETF-Honest" and which he subscribes IETF members to against their will
>> after being told numerous times to cease and desist.
>>
>> Obviously the only recourse is a formal spam compliant with the FTC so
>> the first complaint's filing number is 26303937.
>>
>> I would encourage all of you - and I mean all of you who are as annoyed
>> with this spamming as I am to visit the FTC website and file your own
>> complaint as if there are 10 or 20 of them independently filed, the FTC
>> will in fact take action on this abuse.
>>
>> http://www.ftc.gov/spam
>>
>> Have a nice day.
>>
>> Todd Glassey
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>>
>>
> 
> 

Attachment (tglassey.vcf): text/x-vcard, 125 bytes
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Arnt Gulbrandsen | 3 May 2010 20:06
Picon
Favicon
Gravatar

Re: Formal SPAM Compliant filed against Anderson...

On 05/03/2010 07:48 PM, todd glassey wrote:
> Maybe Joe but I do not want to be a party to his mailing lists, and he
> will not allow me off of them, so I have no choice but to file the spam
> compliant.

I direct your attention to the IETF's standard for unilateral list 
unsubscription, RFC 5228 as extended by RFC 5429.

Dean subscribed me too, but I had forgotten about it until just now.

Arnt
todd glassey | 3 May 2010 20:21
Picon
Favicon

Re: Formal SPAM Compliant filed against Anderson...

On 5/3/2010 11:06 AM, Arnt Gulbrandsen wrote:
> On 05/03/2010 07:48 PM, todd glassey wrote:
>> Maybe Joe but I do not want to be a party to his mailing lists, and he
>> will not allow me off of them, so I have no choice but to file the spam
>> compliant.
> 
> I direct your attention to the IETF's standard for unilateral list
> unsubscription, RFC 5228 as extended by RFC 5429.

Arnt
These are extensions for Sendmail. The problem is that Dean created a
list outside of the IETF and subscribed IETF members to it.  The members
have NO passwords and cant get them without interacting with Dean making
this harassment.

As to whether the IETF postings are commercial or not they clearly are
since they are work on standards for commercial networking.

Todd
> 
> Dean subscribed me too, but I had forgotten about it until just now.
> 
> Arnt
> _______________________________________________
> Ietf mailing list
> Ietf <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

Attachment (tglassey.vcf): text/x-vcard, 125 bytes
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gmane