The historical reason for this is that we were too cheap to pay for a spec.

But now there are political reasons that might well force a break with
ITU-T.


On Wed, Jun 5, 2013 at 10:16 AM, Rob Stradling <[email protected]>wrote:

> On 05/06/13 15:12, Phillip Hallam-Baker wrote:
>
>> Heh, I was hoping not to have to reference that one.
>>
>> The RFCs are meant to specify everything needed to interpret the specs.
>>
>
> Indeed.  It seems odd to me that RFC5280 only references X.509
> Informatively rather than Normatively.
>
>  On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <[email protected]
>> <mailto:rob.stradling@comodo.**com <[email protected]>>> wrote:
>>
>>     On 04/06/13 22:51, Phillip Hallam-Baker wrote:
>>
>>         On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley <[email protected]
>>         <mailto:[email protected]>
>>         <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>
>>     <snip>
>>
>>              Not to mention, does anyone have any idea what an
>>         aACompromise could
>>              mean?
>>
>>
>>         Its an attribute authority. For attribute certs.
>>
>>         Well actually that is only a supposition because none of the
>>         terms seem
>>         to be defined.
>>
>>
>>     X.509 (11/2008) defines the reason codes as follows...
>>
>>     "8.5.2.2  Reason code extension
>>     ...
>>     The following reason code values indicate why a certificate was
>> revoked:
>>        - 'unspecified' can be used to revoke certificates for reasons
>>     other than the specific codes;
>>        - 'keyCompromise' is used in revoking an end-entity certificate;
>>     it indicates that it is known or suspected that the subject's
>>     private key, or other aspects of the subject validated in the
>>     certificate, have been compromised;
>>        - 'cACompromise' is used in revoking a CA-certificate; it
>>     indicates that it is known or suspected that the subject's private
>>     key, or other aspects of the subject validated in the certificate,
>>     have been compromised;
>>        - 'affiliationChanged' indicates that the subject's name or other
>>     information in the certificate has been modified but there is no
>>     cause to suspect that the private key has been compromised;
>>        - 'superseded' indicates that the certificate has been superseded
>>     but there is no cause to suspect that the private key has been
>>     compromised;
>>        - 'cessationOfOperation' indicates that the certificate is no
>>     longer needed for the purpose for which it was issued but there is
>>     no cause to suspect that the private key has been compromised;
>>        - 'privilegeWithdrawn' indicates that a certificate (public-key
>>     or attribute certificate) was revoked because a privilege contained
>>     within that certificate has been withdrawn;
>>        - 'aACompromise' indicates that it is known or suspected that
>>     aspects of the AA validated in the attribute certificate, have been
>>     compromised."
>>
>>     --
>>     Rob Stradling
>>     Senior Research & Development Scientist
>>     COMODO - Creating Trust Online
>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>>
>> ______________________________**_________________
>> wpkops mailing list
>> [email protected]
>> https://www.ietf.org/mailman/**listinfo/wpkops<https://www.ietf.org/mailman/listinfo/wpkops>
>>
>>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
>
> COMODO CA Limited, Registered in England No. 04058690
> Registered Office:
>   3rd Floor, 26 Office Village, Exchange Quay,
>   Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed.  If you have received this email in error please notify the
> sender by replying to the e-mail containing this attachment. Replies to
> this email may be monitored by COMODO for operational or business reasons.
> Whilst every endeavour is taken to ensure that e-mails are free from
> viruses, no liability can be accepted and the recipient is requested to use
> their own virus checking software.
>



-- 
Website: http://hallambaker.com/
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops

Reply via email to