Subject: RE: Unknown private verisign extension

From: Alex Deacon <[email-masked]>
Date: Tue, 30 Nov 1999 15:37:26 -0800

Hello,

Until I get some time to make the VeriSign OID repository ready for public
consumption and place them on our web site, here is a (very) high level view
of what we have done.

--
-- Root of the VeriSign ARC
--  (2.16.840.1.113733)
--
id-verisign OBJECT IDENTIFIER ::= {2 16 US(840) 1 verisign(113733)} 

-- 
-- VeriSign PKI Sub Tree
--  (2.16.840.1.113733.1)
-- 
id-pki OBJECT IDENTIFIER ::= {id-verisign pki(1)} 

--
-- VeriSign defined certificate extension sub tree
--   (2.16.840.1.113733.1.6)
--
id-extensions OBJECT IDENTIFIER ::= {id-pki extensions(6)} 

--
-- VeriSign defined certificate policy identifier sub tree
--  (2.16.840.1.113733.1.7)
--   
id-policies OBJECT IDENTIFIER ::= {id-pki policies(7)}

--
-- VeriSign defined attribute sub tree
--  (2.16.840.1.113733.1.9)
--   
id-attributes	OBJECT IDENTIFIER ::= {id-pki attributes(9)} 

As was mentioned in previous messages

{id-extensions 3} is the CZAG extension (country, zip, age and gender).  I
need to find out if I can disclose the details on this one.  If I can it
will be in the doc.

{id-extensions 6} is a private extension we defined for use in certs issued
to Netscape InBox customers.  I beleive its a simple IA5String.

> 2 16 840 1 113733 1 7 1 1 1 and 2 16 840 1 113733 1 7 1 1 2 mean,
> for some

As for the above policy oids, there seems to be to many 1's in them....

{id-policies 1 1} is the policyIdentifier OID for version 1 of the VeriSign
CPS

You may see other policy OIDS which define policyIdentifiers for our various
affiliates.  Again, these will be listed in the public OID doc.

Hope this helps.

Alex

-----Original Message-----
From: Bill Price [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 2:27 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Unknown private verisign extension

After a series of exchanges with Verisign, I was told that the ... ".1.6.3
OID extension contains country, zip, date of birth, and gender. This data is
masked to prevent misuse or abuse by third parties." (You can voluntarily
provide the information when requesting a cert.)  I was told that I'd have
to contact my sales rep and enter some sort of non-disclosure agreement to
learn how to unmask the data. The designated sales rep has not responded.

Has anyone cracked the masking?

Bill Price

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 24, 1999 4:20 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Unknown private verisign extension
>
>
> [cc'd to PKIX for comment]
>
> [email-masked] writes:
>
> >Included below is a exchange of E-Mails with verisign support. I recently
> >obtained a versign cert and found an undocumented private
> verisign extension
> >in it. It is obvious that I want to know what information is
> stored in that
> >extension. Verisign fails to give an sufficient answer.
>
> I've been trying to find out what 2.16.840.1.113733.1.6.3 and
> 2.16.840.1.113733.1.6.6 are, as well as what the policy qualifiers
> 2 16 840 1 113733 1 7 1 1 1 and 2 16 840 1 113733 1 7 1 1 2 mean,
> for some
> time now, but noone at Verisign will tell you.
>
> This leads to an interesting question: What are the semantics for
> these things?
> As far as anyone knows, the .1 policy could be "By using this
> certificate you
> agree to take full responsibility for any misuse of this certificate,
> regardless of what the CPS says" (which would be perfectly valid,
> since it's a
> policy qualifier), .2 might be "In the event of any dispute,
> Verisign is always
> right", .3 contains a copy of your private key encrypted with
> _NSAKEY :-), and
> who knows what .6 is.  Since the point of a CPS is that both the
> end entity and
> relying party can read it and know what they're getting, wouldn't
> the use of
> unpublished qualifiers and extensions which can modify the CPS destroy any
> possibility of reliance on the certs which contain them?
>
> Peter.
>