Visual RFC.
ALL RFCs / RFC 7468
Read the RFC ↗
RFC 7468 / TEXTUAL SECURITY OBJECTS

Choose the label for the actual inner structure

03

A label names a container, not a particular cryptographic algorithm. Changing the label does not convert the bytes into the named structure. The four scenes are separate label families, not one conversion sequence.

RFC 7468 · § 4EXAMPLE
4 / 4
Choose the label for the actual inner structureSeparate family 4: PUBLIC KEY requires SubjectPublicKeyInfo under section 13; ATTRIBUTE CERTIFICATE requires AttributeCertificate under section 12. No label converts the inner data or verifies trust.Separate label familiesPublic key versus attribute objectPUBLIC KEYtypeSubjectPublicKeyInfoBER · §13ATTRIBUTE CERTIFICATEtypeAttributeCertificateBER · §12Label alone proves no identityThese are separate examples, not conversions
04
Distinguish a public key from an attribute certificate.

PUBLIC KEY names SubjectPublicKeyInfo, not a whole Certificate. ATTRIBUTE CERTIFICATE is another specific structure. All nine labels select an inner syntax; none verifies identity by itself.

Source for this drawing: RFC 7468 · Read RFC section 4 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Route by the correct structure; a familiar name is not a substitute for parsing.

  • CERTIFICATE, X509 CRL and CERTIFICATE REQUEST require BER-encoded Certificate, CertificateList and CertificationRequest structures respectively; DER is strongly preferred. A CRL is a certificate revocation list; a request is not an issued certificate.
  • PKCS7 and CMS require BER-encoded ContentInfo of their respective specifications. PKCS means Public-Key Cryptography Standards; CMS means Cryptographic Message Syntax. Implementations SHOULD generate CMS and SHOULD NOT generate PKCS #7 when CMS is an alternative.
  • PRIVATE KEY contains unencrypted PrivateKeyInfo or OneAsymmetricKey. ENCRYPTED PRIVATE KEY contains EncryptedPrivateKeyInfo. PUBLIC KEY contains SubjectPublicKeyInfo, including algorithm information and public-key bits. These require BER with DER preferred.
  • ATTRIBUTE CERTIFICATE contains AttributeCertificate in BER, with DER strongly preferred. It is a separate authorization-related structure, not an alternate spelling for a public-key certificate.
  • Generators MUST use CERTIFICATE, X509 CRL and CERTIFICATE REQUEST, not X509 CERTIFICATE, X.509 CERTIFICATE, CRL or NEW CERTIFICATE REQUEST. Parsers SHOULD NOT equate the first three old certificate/CRL labels with the standard ones, but MAY accept NEW CERTIFICATE REQUEST. Generators MUST NOT emit CERTIFICATE CHAIN; parsers SHOULD NOT equate it with PKCS7.
DETAILS

The label map covers all nine types in §4. PKCS #1 RSA PRIVATE KEY and OpenSSH formats are outside this RFC. File suffixes do not prove the encoding: §5.3 recommends .crt for textual certificates while noting common .cer practice.

Read the RFC section ↗

All chapters in RFC 7468

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗