Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 8 Jan 2011 13:23:12 -0600 (GMT-06:00)

warren and all,

  Good compermise third option IMO.

Kindest Regards,

Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
IT/network security Eng. SR. Eng. Network data security,
IT/information and web security.
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

-----Original Message-----
>From: Warren Kumari <[email-masked]>
>Sent: Jan 8, 2011 1:04 PM
>To: Paul Hoffman <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Starting to work through the issues: Issue #4 --	"Identification of hash and cert types."
>
><chair hat>
>Boys! Please...
></chair hat>
>
><no hat>
>Ok, so I'm proposing a compromise here as a third option. As this is a  
>compromise, I'm assuming no-one will love it, but maybe folk will be  
>willing to accept it...
>
>We ask the IANA to create us a registry (I'm proposing 2 octet  
>codespace, with some portion chopped out for experimental values --  
>this gives us >65k usable values (and I don't want to live in a world  
>where we approach that :-P), but that's just a thought). ODI can be  
>assigned a value from this space, and once / if everyone discovers  
>that they like it, folk will no longer bother trying to get  
>assignments from our registry, which would remove the "registering new  
>values" burden from the IANA.
>
>
>The obvious downsides are:
>1: If ODI becomes the standard that everyone converges on,  we will  
>have burnt 16 bits for nothing.
>2: In instances where ODI is used the "payload" will not be in the  
>same place in the structure. Implementations that do not support ODI  
>obviously just treat these as they would any other case where they do  
>not understand the identified algorithm / registered value....
>
>The parsing for this is simple (in c-ish psudocode):
>switch (dane_struct->codepoint) {
>   case  CP_SHA_256:
>       handle_sha256(dane_struct);
>       break;
>   case CP_SHA_512:
>       handle_sha512(dane_struct);
>       break;
>#ifdef HAVE_ODI
>   case_CP_ODI:
>       handle_odi(dane_struct);
>       break;
>#endif
>   case default:
>       debug("Not yet supported algorithm number: ", dane_struct- 
> >codepoint);
>       break;
>}
>
>
>To my mind, these downsides are minor... Thoughts?
>
>W
></no hat>
>
>
>On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote:
>
>> On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote:
>>> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>    On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:
>>>
>>>        Since this is precisely the type of change that KEYPROV was  
>>> required
>>>        to make during IESG review, I would have to disagree.
>>>
>>>        We had specified our own password string prep, we were told we
>>>        had to
>>>        use the existing string prep from another spec.
>>>
>>>
>>>    The "precisely" in the first paragraph completely disagrees with  
>>> the
>>>    second paragraph. The format of the identifier is completely
>>>    dissimilar from a modification of a difficult internationalization
>>>    process.
>>>
>>>
>>> No, it was a change the WG debated at considerable length when  
>>> there was
>>> no need to as it was not a decision it should have made.
>>
>> Then you should blame the WG chairs (you were one of them).
>>
>>>    That's fine for you to predict, but I predict differently. I think
>>>    if we choose either a short numeric identifier (as is already used
>>>    in most DNS protocols) or an OID (as is already used in PKIX and
>>>    S/MIME), the IESG will be fine.
>>>
>>>
>>> We also had a draft written by the current IETF chair and one of the
>>> IETF Security Area directors that converted all our XML formats into
>>> ASN.1. The other Security AD told us to add it as a WG item.
>>
>> Correct. If this WG was considering having our algorithm identifiers  
>> as XML structures, we might have the same. Fortunately, we don't.
>>
>>> Have you any idea how much the security area likes ASN.1?
>>
>> Having written a handful of Security Area RFCs that use ASN.1: yes,  
>> I do.
>>
>>> Here you are interfacing to PKIX which is an ASN.1 spec.
>>
>> So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with  
>> PKIX in a similar fashion, and neither are in ASN.1 format. To the  
>> best of my knowledge, no one ever suggested that they should be.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

---

From: =JeffH <[email-masked]>
Date: Mon, 10 Jan 2011 11:11:39 -0800

PaulH replied..
 >
 > On 1/7/11 3:12 PM, Warren Kumari wrote:
 >
 >> If possible I'd like us to try and separate the discussions of "Who gets
 >> / how to get an identifier for an algorithm" from the question of how we
 >> actually identify these -- while I realize that there are
 >> interdependencies in the two issues and they are not fully separable,
 >> I'd appreciate it if we can try and separate them as much as possible so
 >> that it is easier to call consensus....
 >
 > Just to be clear, my preferences are:
 >
 > - Somewhat liberal policy for assigning: "RFC published", not "IETF
 > consensus" or "expert review"
 >
 > - two-byte integers for identifying, with 1000 reserved for private use

+1

altho we could probably get by with just one octet for hash alg identifiers, I 
wouldn't go to the mat over having two.

HTH,

=JeffH