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: [email protected] Twitter: RichSalz
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
