Re: [Trans] Use of private OIDs in WG document

[Rob Stradling <[e-mail]>]

RFC6962 defines 4 OIDs under Google's OID arc.

1.3.6.1.4.1.11129.2.4.3 (the Precertificate Poison certificate 
extension) and 1.3.6.1.4.1.11129.2.4.4 (the Precertificate Signing 
Certificate EKU OID) are both no longer required, due to the 
Precertificate format change.  They've both been removed from 6962-bis.

That leaves us with 1.3.6.1.4.1.11129.2.4.2 (the 
SignedCertificateTimestampList certificate extension) and 
1.3.6.1.4.1.11129.2.4.5 (the SignedCertificateTimestampList OCSP 
Response extension).
Ticket #10 (see comments 6 and 8) intends to extend and merge these two 
extensions into one new extension with a new OID.

I see no reason why we shouldn't use an OID from an IETF OID arc, as I 
wrote in ticket #10 comment 9.

6962-bis currently defines 1.3.6.1.4.1.11129.2.4.6 (the Redacted Labels 
certificate extension) and 1.3.6.1.4.1.11129.2.4.7 (the certificate 
extension to permit a Name-constrained intermediate CA certificate to be 
logged in place of end-entity certificates).
I see no reason why we shouldn't reassign these from an IETF OID arc too.

I am working on the assumption that "Russ, we're gonna need some OIDs 
for some cert/OCSP extensions - please can you assign some now, even 
though we haven't finished specifying the contents of these extensions 
yet?" would be greeted by a firm "No".  Hence why the draft is still 
using OIDs under Google's OID arc.


[1] http://trac.tools.ietf.org/wg/trans/trac/ticket/10

On 29/03/15 16:00, Russ Housley wrote:
> In this case, the document was published with OIDs from a non-IETF OID
> arc long ago.  I see no reason to disrupt those implementations, and in
> fact, having two OIDs with exactly the same semantics is confusing.
>
> If new OIDs are needed, we ought to assign them from an IETF arc managed
> by IANA.
>
> Russ
>
>
> On Mar 28, 2015, at 1:14 AM, Massimiliano Pala wrote:
>
>> Hi Rich,
>>
>> I do not think there is any precedence about using private OIDs for
>> I-Ds - the use of Google's OIDs is ok at Google, not for a standard.
>> The first reason is because Google's controls its own sub-tree and can
>> change the sub tree at any time - not appropriate for an RFC. The
>> second reason is that, since the document is defining extensions for
>> certificates and OCSP messages (both under PKIX), the natural place is
>> actually under PKIX.
>>
>> I also want to point out that OIDs are not just opaque identifiers -
>> if that was the case, we would not use a hierarchical structure. The
>> sub-tree where the OID is is actually important.
>>
>> This said, I have two questions for you:
>>
>>  1. Why this would not be the appropriate base OID ?
>>  2. Which base OID are you referring to when you say "under IETF" ?
>>
>> Cheers,
>> Max
>>
>>
>> On 3/27/15 10:58 PM, Salz, Rich wrote:
>>>
>>> OID’s are just distributed opaque identifiers.  Doesn’t bother me,
>>> but if the WG wants to change OID’s and break deployed software, go
>>> for it
>>>
>>> It will might be hard to get a PKIX arc.  A Trans arc under IETF
>>> seems more feasible.
>>>
>>> --
>>>
>>> Senior Architect, Akamai Technologies
>>>
>>> IM: [e-mail] Twitter: RichSalz

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online